Details

Published: 22 September 2014

While there are not that many exciting news to report lately, a lot of progress is being done in two frontlines: the CAS and the hardware abstraction layer.

The CAS rule matching engine is being rewritten from scratch. Now it uses a different approach to make substitutions faster and with much less memory management overhead. This is achieved by using the algebraic expressions "exploded' in the data stack. Inserting/replacing variables is a matter of stack operations, and the final symbolic object is not reassembled until all processing is finished. The new engine is capable already of applying simple substitution rules, (like X->A+B), with the more complex parts to follow.

Other minor improvements are in the compiler/decompiler, which can now properly parenthesize expressions to make expressions look better (for example 'X*-2', although a valid expression, is now shown as 'X*(-2)'. There's also some simple autosimplification rules that are applied to sanitize expressions after exaluation. It resolves all numeric operations without altering the structure of the expression. For example 'X+2*A/4' becomes 'X+A/2'.

Finally, the hardware abstraction layer for the 50g target is taking shape. Firmware boots reliably into a virtual memory space, and the basic services are being debugged and tested (basic services as in exception handlers, IRQ handlers, timers and keyboard).

The system will run at 2 different clock speeds. 6MHz will be used for low power consumption and 192 MHz for computing. The switch between the speeds will be done automatically by the timers and the keyboard modules. When the calculator waits for a key, it's put in slow mode and a timer will be started that will expire after a short period of time (around 500 ms, user configurable). If the calculator is back checking the keyboard before the timer expires, it's assumed that the user is doing input, so the timer is reset for anoter 500 ms and the calc is kept in low power mode. If the calculator doesn't check the keyboard for a long period of time, the timer expires and it switches the CPU to high speed.

This timer will control the "responsiveness" of the system. Any operation or program that takes longer to execute (at 6 MHz) than the limit for the timer, will activate the turbo mode. Setting the timer short will make the system more responsive, at the expense of power consumption.

This operation should result in longer battery life, likely longer than the original 50g firmware. For comparison, the original firmware runs at 12 MHz in slow mode, vs. 6 MHz in newRPL. It switches to turbo mode every time it executes a program, while newRPL will switch only if the program takes too long to execute in slow mode. This means for normal number-crunching and stack operation it will remain in slow mode permanently, since those operations are very fast (keep in mind that even in slow mode, newRPL is still about 16x faster than the original RPL at full speed).

Details

Published: 09 August 2014

After a summer break without publishing demos, our third alpha release is out. Unfortunately, the symbolic rules engine wasn't ready so it's not included yet in the demo, but symbolic objects can be typed and compiled. Evaluation of symbolics does variable replacing but no automatic simplification yet, since it will be mainly rule-based. This means 'X+1' EVAL with 1 stored in 'X' will return the symbolic expression '1+1'  and not the expected 2. This of course only reflects the "work in progress" status of symbolic support.

Complex numbers are also ready for testing. The basic object is implemented and the basic operators are finished, although many of the math functions are not yet ready to return complex numbers (-2 SQRT will not give the expected result).

Enjoy the demo while we keep making silent progress.

Details

Published: 01 August 2014

Another milestone for newRPL was reached. For the first time, our custom firmware was flashed and executed on the 50g hardware. It doesn't do much yet, just take control of the CPU, memory and LCD, display a few pixels and loop indefinitely. While this isn't much of an operating system yet, it means the project is setup for building custom roms (cross-compiler, makefiles, linker scripts, and a tool to extract the binary data from the generated ELF executable). Everything is in place to begin serious development.

The rom was flashed using the standard procedure: putting the file in a SD card, together with a file called 'update.scp' containing the name of the rom file. The calculator accepted the new ROM and flashed it without hesitation. A few milliseconds later the pixels were showing on the screen, just the way it was supposed to be. Resetting the calculator with the +/- keys pressed gave back the option to flash the calculator, proving that the calculator wasn't bricked, and that there were no permanent consequences in using the custom rom (it can be flashed back with a normal ROM anytime).

Next steps are to develop the basic services that newRPL will need: MMU management and basic drivers for keyboard, screen, timers, clock, SD card, and power management.

It's still a long way to go, but we are on the right track and pushing forward.