The development version is most likely what the first preorders are gonna be and is the version which the developers in the community will use to develop the software for this calculator. The development version is basically the same as the Professional version, except it lacks WiFi and the integrated battery pack. This will keep the costs under $200 which is what you guys seem to want. The WiFi module and integrated battery is just too expensive I believe for most of us now anyway. I need to think about it more and look around if I could make it any cheaper. If you decide to preorder a development version and you really want WiFi though, you may be able to add in WiFi later on using the expansion port built into the calculator.

Let's keep the Wifi for professional/dev version. One of the things is that the "Pro" version will (and must be) designed differently. Here, you're aiming for a VERY (and I mean VERY) sweet spot - scientific research. Besides it being a calculator, it can also become a sensor for data collection! (Scientists have used the iPod Touch a LOT for data collection - via not so pretty ways, mind you. The headphone jack comes to mind...)

The "expansion port" must be standardized, or have open specs on usage. Otherwise, it won't look too appealing.
Also, the "pro" version should be pretty thin - the physical keypad can be hidden under the touchscreen and pulled out as needed.

I'm thinking of making the Professional version have a portrait display (240x320), with a smaller and simplified keypad to compensate for the cost of the WiFi module. However, programs and software that are dependent on how the screen is rotated would be affected. I suppose you could rotate the Professional version by 90 degrees if you need the landscape orientation.

For what purpose? I'd think it could be multidirectional if needed. Again, it's all about software and a bit of GFX acceleration to perform text rotation. Regular can just be locked to landscape, but pro should have an option. Remember, we're not making an iPod Touch here!

Quote from: graphmastur on February 03, 2011, 07:27:59 am

How open will this be? Will you document EVERYTHING?  Also, how does the flash chip and such work? Do you have to erase entire sectors of stuff to get it to flip a 1 bit to a 0 bit?

All the hardware is taken care of by the Linux kernel. You can look at the kernel sources and the drivers I've written when I get around to uploading them into a repository. Pretty much, programming this thing feels just like how you would program your computer. You can write your programs in Java, Python, C/C++, whatever. You don't need to depend on any SDK or hack it to get some code running. It's that open. If you have questions, I'm here and will be glad to answer them. That being said, you don't really need the schematics as they are not necessary to do programming for this calculator. You guys have been able to program your calculators, computers and laptops without any schematics as an example. Also, I don't want clones or cheap ripoffs being made. It would make all the effort, time and all the money I fed into the project a waste.

I can respect your decision here. Software is pretty easy to make, and will be FOSS, but HW is a bit on the edge. I do ask though that you provide a standardized expansion port. If not standard, provide open specs and examples. Any interfacing and such with the USB must also be open. (This includes charging, etc.)

@alberthrocks: This calculator will downclock itself since CPU frequency scaling is supported in the Linux kernel. The new processor which I plan to use will even go a couple of steps forward and disable and power down certain blocks of the CPU when the hardware is not in use further using less power. Plus, it's also manufactured on a smaller die. You will also have the option to turn off the backlight and dim the brightness of the LCD.

Ahh, but it *won't* downclock itself automatically. It's SUPPORTED, but not really "turned on". You will need to download cpufreqd or cpufrequtils, and play around with them to get true support working. THEN you'll see that battery life improvement.

As for the power down of the screen, backlight, etc... a couple of things:
- Aim for a non-reflective screen. They're annoying, and if you execute it properly, you can get the backlight off (or almost off) and still be able to see the screen in a classroom.
- A daemon will need to be written to control this.
- For powering off...
--> If left on standby, screen should fade down in 30 sec - 1min, then the screen should turn off in 30 sec - 1 min, then go to sleep in 1-2 minutes, then hibernate in 5-10 minutes.
--> If turned off via button(s), screen should turn off immediately, and the system can go to sleep in 30 sec - 1 min, then hibernate in 3-5 minutes.
--> These settings are all user controllable. The numbers specified above are pretty conservative - the software should practice aggressive power management. It must be better than the Nspire AND the iPod Touch at battery life. Reason? Obviously, for the calc market, better life is a good thing, and then if an iPod Touch that plays music, surfs the web, etc. continuously beats this.... then it's obviously not a good thing either. (iPod Touch can do 40 hours of continuous music, not sure about Nspire battery life.) Of course, the iPod Touch has a decent battery inside, so we'll be a bit nicer.

As for a testing mode, I have to think more about that. The problem with this calculator is that it's just too open and flexible, software wise. I'm pretty sure whatever "lock" I can place on this calculator, someone will find a way to circumnavigate it. What I could do probably is place in a hardware switch that shuts off power to SD slot and expansion port, disables the USB and disable access to some regions of Flash memory with an LED indicator that the switch has been flipped.

Ahh, that's like saying all FOSS is insecure because they're open source/HW, eh?
Case in point: OpenSSL and OpenSSH. Both are purely FOSS, and a quick search yields the source code in seconds. But as much as you read it, it's pretty impossible to hack it. And for exploits that have been found - they are found by the best security researchers in the field, not some amateur hackers like us.

You get my point here, right? Here are some ideas: (can be combined or separate)
1) Separate the testing mode into a immutable flash chip, and with a simple HW flag (and a file on the data side of the writable chip), lock it as such. This needs LOTS of testing for the testing OS, since it can't be changed afterwards.

2) Have a encrypted signature check just to see if an official OS is installed or not. If not, turn on a flag that indicates a third party OS is used and warn the user that installing the OS will make the calculator unusable on the test.

3) The bootloader has a hook that when the keys are pressed, takes over the display and shows the dialog asking the user about going into testing mode. This replaces the OS's key detection, and can be used with #2.

4) Lock the test lighting with an AVR/some little chip with encryption and such, and the testing OS can only access it. (This seems to be a bad idea...)

Seems cool, but for the standard version would the audio jack always remain disabled with no way to enable it? If so, then it might be best to just not put any audio jack at all in that version.

As for the different screen on the pro version I think it should remain compatible, although I guess the screen could be rotated, assuming it's not too hard to play games and use software with the calc sideways. X.x

Seconded - I/O ports are an oldie these days. See below for my opinion on screens...

I hope that the "ultimate" version will have compatibility with programs for the less powerful calc versions that use the keypad/screen in unique ways.

And a rotatable screen would be nice. Incompatibility is not very well liked in the dev community, and you want a lot of people to adopt it!
(The scientific people in general are watchful for compatibility, and doesn't take anything but it.)

I'm assuming that you will go over how to create a cross-compiler for C?  Java might be a little much, unless the ARM processor supports it natively.

It shouldn't be too hard, but this is a must have as a wiki document or something for this project. Maybe even include it in the manual!

But what's the point of having Java if it's only on one real platform?

Well java would be cool since some people like it. Ashbad do you mean it's only available on one of the 3 Project Paradise calcs? I am confused

I think Java is just as a portal to the innerds of UberCalc, including the interface, I/O, and possibly the math part too.
However, Java is NOT to be used as the core. It's not very pretty if it's just used for everything, since it's pretty slow, especially without ARM accelerated support. Android is an example - you need at least 1 GHz to have a jitter free experience.

Quote from: graphmastur on February 04, 2011, 09:53:21 am

I'm assuming that you will go over how to create a cross-compiler for C?  Java might be a little much, unless the ARM processor supports it natively.

Yes, I plan to have a wiki by the time preorders are ready. As for Java, I've been using OpenJDK and all the Java programs I ran seem to run fine on the first prototype. The final design has a faster processor and more RAM, so everything should be ok. Plus the processor has Jazelle. I'm not sure though if OpenJDK supports Jazelle.

@DJ_Omnimaga, I think Ashbad was referring to graphmastur's post. All three versions will be software compatible with each other.

Some good news, I might be able to get funding to build a prototype of the final hardware design soon. This should be exciting as it will be a good indicator of when preorders can start. I will keep you guys updated.

Java is OK as long as you don't use it as a core or GUI. I would stick with Python or C/C++.... heck, I wouldn't even recommend Python! You have to have a fast and stable core, and then branch out with APIs for languages like Java, Python, Perl, etc. (and of course, BASIC! ) We emphasize on the speed factor here as it's part of the marketability of this product.

I'm going to assume you mean this Jazelle (and not one of the older specs):
http://www.arm.com/products/processors/technologies/jazelle.php?tab=Jazelle+Architecture

Jazelle might be supported, sourcing the following links of hope:
http://www.bugcommunity.com/wiki/index.php/Try_openjdk_with_jazelle
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-July/002748.html

Jazelle is proprietary, and can be costly (so I've heard) for licensing with Java, so beware.

And congrats on your funding sourcing success! I hope to hear more about this project in the upcoming weeks/months!

THIS IS FREAKING EPIC!

Good luck with the funding uberspire!

Also I agree with the non-reflective screen suggestion. I prefer like my computer LCD or my Casio FX-9860G rather than CRTs or my Casio Prizm. With lights around we barely see anything.

I think the "e" and "θ" keys should be switched, but otherwise...

That. Is. Epic.

 

I think the "e" and "θ" keys should be switched, but otherwise...

Heh yeah, I agree with you, the numbers should have been grouped together. If you swap them, you can almost type out Euler's identity with one row of keys (except for key 1).

Also does this calc have a dedicated sound proc.

There's no dedicated sound processor, but all sound is handled by the ARM9 processor. I'm pretty sure it won't have any trouble decoding MP3 and WMV files.

Wow, awesome topic, and awesome progress you've made with this thing. About the current design; isn't a qwerty keyboard a no-go with on standardized testing as they consider it a computer?

*edit* Just noticed that the specs seem (off the top of my head) very reminiscent of a PSP. 

Im totally wanna buy the developers edition.  No hands down.  How much?  Whatever it is is worth it.  this is beyond awesome.  it's uberawesome.

How long until a possible developer's release?