Latest DIY calculator news

[Eric Smith]

I just gave my presentation at HHC 2012. The news is that the DIY4X now runs a modified version of Thomas Okken's "Free42" software.

The LCD display has eight character rows, rather than two in the original HP-42S and in Free42. I reserve the bottom row for soft menus, so that everything else doesn't move up and down when the menus are activated and deactivated. In run mode, all four levels of the stack are displayed, and any error messages are shown at the top.

In program mode, seven program lines are displayed, and the scrolling is done such that whenever possible, at least two lines before and after the current line are displayed.

The DPLOT program from the 42S user manual works with only two lines changed to take into account the larger display.

The display hardware is capable of 400x240 pixel resolution. It is strictly black and white, though grey can be obtained by dithering. The Free42 code was written based on a 131-pixel wide display, so currently the pixels are scaled by a factor of 3 on both horizontal and vertical axes. Later I hope to make Free42 work at native resolution, which will look much smoother.

A subset of the HP-IL Mass Storage functions are implemented, allowing saving programs to and loading programs from a MicroSD card.

There is USB support in the bootloader, allowing firmware upgrades from either the MicroSD card or a host computer via USB. The calculator does not currently have USB support, though I plan to add it, making it look to the PC like a communications devices. The calculator will use HP-IL control functions such as OUTA to talk to the PC.

We didn't get the DIY5 hardware completed in time for the conference. It will have the 42S keyboard layout and the form factor will be similar to the 20b/30b.

[Paul Dale]

Nice!

- Pauli

[Raymond Del Tondo]

That sound great:-)

Quote:

---

[..]We didn't get the DIY5 hardware completed in time for the conference. It will have the 42S keyboard layout and the form factor will be similar to the 20b/30b.

---

Please don't use the awful housing of the 30b. A housing similar to the 17bII+ silver would be much nicer.

However, I wish you and the other HHC attendees a nice and informative Sunday:-)

[Eric Smith]

The housing definitely won't be like the 20b/30b. The point was just that the overall dimensions will be close.

[Ángel Martin]

Salivating over the news, looking forward to the release... :-)

[Walter B]

Sounds promising for both DIY4X and DIY5 :-)

[Harald]

Very much looking forward to further updates and pictures on the subject!

[uhmgawa]

Quote:

---

...modified version of Thomas Okken's "Free42" software.

---

Would this be a fork of Free42 or are your modifications intended
to be incorporated into Thomas's codebase? I'm particularly
curious of the footprint you've been able to achieve. I did
look briefly at paring down Free42's sprawl, but suspected a
significant reduction would require major modifications to
the code. Also are you using the toolchain's binary FP or BCD20?

[Paul Dale]

You'll also have to watch for memory fragmentation. A calculator either needs a static memory layout or compacting garbage collection.

- Pauli

[Eric Smith]

Yes, I've been worried about memory fragmentation since I first looked at the Free42 source code some years ago. I think the only way to solve this problem in Free42 without a massive rewrite is to implement a double-indirection scheme similar to the "handles" used by the original MacOS (up through 9, not X).

When I brought up the issue in email with Thomas, he suggested the very same thing.

[Paul Dale]

Funnily enough, I was seriously considering the same approach for the 43S.

- Pauli

[Walter B]

Quote:

---

I was seriously considering the same approach for the 43S.

---

We shall seriously think about and carefully choose the name of any new calculator. While we always talked about a 43S as the dream calculator after the HP-42S and the WP 34S, I begin to doubt it will be a good choice ...

[Andrés C. Rodríguez (Argentina)]

Hi Paul and Eric:

If possible, please suggest readings about the "double indirection" method. Also, any comment from you will be most welcome. The topic of "memory management" and "memory fragmentation" is present in one of my courses, and I would like to give some extra information to the students. A real-world, current case as the DIY-X or WP-34X will be most interesting to mention or discuss, even without full depth analysis.

Thank you in advance.

Andres

(a#.#rodriguez "at" ieee#.#org) Please remove "#" as appropriate.

[Paul Dale]

MacOS memory management

- Pauli

[Andrés C. Rodríguez (Argentina)]

Thank you!

[uhmgawa]

Quote:

---

If possible, please suggest readings about...

---

It's just the pervasive problem of aliasing memory object
addresses to something more manageable in the associated API.
Should the object move or be deleted the API can detect this via a
simple operation on the alias handle and take appropriate action.
Common examples include include file descriptors, process ids, etc..

[Eric Smith]

I've sent the display modifications to Thomas. It is not yet determined whether he will merge them.

As per the GPL license, the source code as used in the calculator will be published when the calculator is made available.

The calculator is using BCD20. The processor does not have floating point hardware, so there is no benefit to using IEEE binary floating point. I'd prefer to use decNumber, but haven't yet tried to put it in.

[uhmgawa]

Quote:

---

As per the GPL license, the source code as used in the calculator will be published when the calculator is made available.

---

My question actually was of whether this effort would be in the
context of an open project (public code repo, etc..). I don't
think even a major modification of the codebase is unreasonable
to reduce both static and runtime footprint. However attaining
sufficient traction to maintain the effort on a long term
basis would otherwise be my concern.

Quote:

---

The calculator is using BCD20. The processor does not have floating point hardware..

---

While BCD20 does make an effort to map operations assuming
the availability hardware arithmetic instructions, I would
still expect a straight binary representation to be more
efficient. Not that I'd recommend using the latter, but was
curious if you'd configured for both and had any rough
performance metrics relative to a cortex m3.