This is a pretty neat project. If I were to get one it'd have to be either pre-assembled or I'd have to get someone to put it together for me as I have zero soldering experience. Also, I know it'd cost more, but I think a higher res colour screen would be a nice option to have.

Thanks. I am going to offer hand assembly for those who are interested for a fee. Don't worry though. I am not going to charge much.
But, I was considering donating one hand assembly as a contest price to boost activity here a bit. The winner would still have to pay for parts+shipping though.
About the color screen, I have heared that a few times now. But this would mean starting from scratch and would also greatly increase power consumption and most importantly the price.

One big question is, whether it is a good idea to make the mainboard in two halves or not.
The big benefit of one unified mainboard is, that it allows me to integrate everything into one nice and working design. There is a lot less to do for the user.
In fact, it could be made to a form, that soldering is not required anymore and the user can just open the case of the dead calculator, remove all screws and the original mainboard, remove a few plastic supports with a knife and screw the new one in. Then connect the battery and close the case again.
However, this would bind users to the Raspberry Pi Zero platform, which is really nice in my opinion, but makes the project dependant on it.
The two board solution would be taking care of this issue and would also enable the user to make boards without the Pi, but it is more advanced.
I think I will go for the one, unified mainboard and provide gerber files for just the keypad with the Arduino Uno for those who want just that.

UPDATE:
I estimate the savings of a 1 board solution vs the 2 board solution to be around 30-40%.



Here's another quick preview of the board:


Note that the LCD is *almost* as big as the old one.
While it fills the screen exactly when it comes to width, it's not quite tall enough.
Therefore the is a really slim, barely noticeable, black border on the top of the screen.

Another issue I am currently struggeling with is connector placement.
There seems to be no room to fit the USB nor the phono jack.
Maybe someone has some creative idea, how to mount them?

For completeness, this is how the LCD (minus the backlight, which just does not fit), looks like:


EDIT:
The USB and Video jack issues have been resolved.
I have found a slim profile micro USB that will fit with just a minor amount of plastic removal.
For the Video, I will be using a simple Dupont header. There is just no space for any "real" connector except for maybe some kind of coaxial one.

So I will be resuming work on the VM now. I have now decided to make a PC and then an ARM and an AVR port. Later there will be a z80 port too.

So I finally, after months of work, completed the Assembler 
I would be glad if you would please give it a try

The universal binary can be downloaded from here: http://data.bmuessig.eu/Projects/Clawsemble/alpha-160923a/
Despite being a .exe, it runs fine on Linux and Mac. Actually, I am developing this on Linux.
It requires Mono (or MS .NET FW) to run on all of them.

Looks pretty neat. However, I should point out that you've somehow lost all the plus signs (not just here, on git as well).

Are floats not part of the plan? I'd be slightly disappointed if that's the case. I recognize the pain of supporting them on hardware without an FPU (or even a good ALU), but any programs involving serious math or graphics really need them.

Thanks
Oh, and thank you for pointing that out. I have really not noticed that
EDIT: FIXED.

Floats are not going to be part of the default instruction set. Floats are not going to be part of the default extended instruction set. They might be something added to the extended instruction set at a later point, but they will be one thing, incredibly slow. Fixed-point however, will be supported by the default extended instruction set and it will certainly be a lot faster
This design limit was set early on, as really none of the platforms I am targeting have a dedicated float processor or float instructions. Most platforms are 16 or 32-bit microcontrollers or the 84+ which all use soft float. Using float for the main data type would be totally silly and adding more than one data type is making everything way too complex and RAM-consuming.

I have finished the instruction list. A lot was already there but I have finally completed it.
Can you PLEASE have a look if I am missing anything and maybe suggest some improvements?

Here is the full instruction list:
https://docs.google.com/spreadsheets/d/1Tfi8z7maQLM3RUHfQpnS50gAkGyfiizkQ54TTZGl9e4/edit?usp=sharing


Also, here's a little Clawsemble preprocessor overview for all of you:

Let's start with the conditionals.
They can be nested as much as desired and each if can have an unlimited amount of elseif's/elseifdef's and elseifndef's.
There can only be one else which is optional and has to be the last element in the if block.
#if (expression)    is used to only process the enclosed code if the condition is met, or the number or string inside the parantheses is non-zero
#ifdef defininition    is similar to the above but the condition is met, if a variable with the name is defined
#ifndef definition    as above, but condition is met, if the variable is not defined
#elseif (expression)    is used to provide an alternative, if the previous condition(s) is/are not met
#elseifdef definition    as above, but the condition is if a variable with that name is defined
#elseifndef definition    as above, but the if the variable is not defined
#else    if the condition is not met and the elseif's don't met their conditions either
#endif    is used to close the if-block

Expressions are simple.
All C arithmetic operators are supported and are using the same symbol, except for modulo, which is // now.
Numbers can be written with +/- prefix to show whether they are positive or negative. Negative numbers do
not need to be enclosed in parantheses. You can easily write something like: (-1 + -2 -3 - -4) and you can
even omit the spaces and Clawsemble will still be able to deal with it correctly.
Using the negative sign to negate an expression is NOT supported though. Use *-1 to do so instead.
Expressions should always be enclosed in one set of parantheses ()
Hexadecimal numbers are prefixed with an $ABAB, characters are written like this %d.

Multiple files work too.
Just use #include "filename.csm", to include other source files. They are just inserted into your main program at the position
of the #include statement and have access to the same #defines as your main program.

You can define variables.
Use #define MY_VAR 1234, #define YOUR_VAR %d, #define HEXVAR $DEADBEEF or #define ANOTHER_VAR (123 + $1242 * 123) to define your own variables
that you can check later on with the #if statement and it's companions. #undefine is used to delete a variable from memory again.
Variables can also be redefined at any point by simply calling #define again.
Be careful with the names, as they are case-sensitive. Also, all exact word-occurences of the variable name in the program are
automatically replaced by the value that the variable has at that point of time. If it changes later on in the assemblation,
the value won't change again.

Custom errors are easy to use.
Let's say, you have some conditions that have to be met for a program to be assembled correctly and you would like to prevent
the user from such accidents then you can simply use the #error statement to abort the further assemblation of the program.
You can even display an error message, the result of an expression or the contents of a variable by passing it after the #error statement:
e.g.: #error ("The architecture " + ARCH + " is unfortunately not supported at the moment!")

Make it short.
Many shorthand forms are available to save you typing:
#error, #err
#define, #def
#include, #inc
#elseif, #elif
#elseifdef, #elifdef
#elseifndef, #elifndef

Comment your code.
You can use the ; character to comment out lines if you don't want them to be parsed.
Everything after the start of a comment until a newline character is ignored and will not be processed.
You can put the comment at the beginning or the end of a line. Multiline comments are not supported.
Comments can be disabled by putting a \ in front of the comment. Like this:    \;
The \ character can also be used to break single line codes into multiple ones:
e.g.: #define MY_COMPLEX_EXPRESSION \
(123 + 124 + 23230 + 12040 + ONE_OF_MY_VARS + 12332 * 124224 - 20 + \
1402 + $BEEF)


This tutorial will be finished later on, when more of the assembler is done and ready for primetime.

Thank you and congrats. Now is a lot more clear! Keep it up an good luck 'cause it looks rather versatile, so to speak.
I'll be looking forward to give it a go, when it becomes available for testing.

I would love if you could test the mathematical preprocessor of Claw. Details follow:

So, I fixed a ton of bugs since the last post and added quite a few new features.
Also I finished the mathematical part of the preprocessor.

So I need your help now, by testing the robustness of the preprocessor.

The latest snapshot can be downloaded here:
http://claw.bmuessig.eu/dl/

It can be run on Linux by:
mono ./csm.exe ./Sample01.csm
or on Windows:
csm .\Sample01.csm

Please try breaking it in a mathematically and syntactically valid fashion. I would really appreciate that.

Have fun!

So this is like a custom language? How does it work? Does it compile to bytecode which gets interpreted?

This is a three part system. There is an assembler or a planned compiler that will be used to generate bytecode. These are .cxe files that can be run in the Claw VM. It's similar to Java, where you write something once and run it on several systems without (much) modification. But Claw is targeted at embedded electronics such as Calculators, Arduinos, and similar electronics.
Code stays binary compatible between platforms, as Claw uses (kernel-) modules and libraries to implement native functionality and therefore does not rely on platform-specific code.
Claw is designed to completely try not having to worry about platform-specific things (too much).
E.g. graphics are plotted to a virtual canvas that translates to the actual screen. Vector graphics are preferred over normal bitmaps, as these will simply be blown up in squares.

It does get compiled to bytecode, yes, which is then run in a platform-specific virtual machine.

Not very clear to me either.

A  couple few questions:
1. How do/can you interface with the embedded system? GUI (eg, xml), High level language (eg. Java, C++), Assembly language, other?
2. What's the Claw timeline? When do you think you'll have a prototype ready that runs, say, on Windows or Linux or on a real embedded system OS.

I'm afraid this presentation is a bit difficult too general, abeit it seems interesting.

1. There are two custom languages. One being Claw HL which is a Lua like language and then there is Clawsemble which is just assembly instructions for the virtual machine.
Claw has some custom audio and image formats that allow writing graphics code once and actually running it everywhere. More about that later.
2. The Claw Assembler is quite far already and I plan finishing it that week. The VM is halfway done; arithmetic, stacks, array pool and call stack are mostly or fully implemented. Missing are still the jumps and some basic file loading. Also there are no modules yet (e.g. string, graphics, io, network, ...).