▼
Posts: 134
Threads: 31
Joined: Oct 2011
Have any of you involved in the development of the WP34s given any thought to the concept of hacking a 15C-le into an emulation of the 16C?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Maybe a 12C+ is the better choice because it is easier to get.
You'll need a firmware image to patch the 16C ROM in. This is not (yet) available for the 15C.
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
Have any of you involved in the development of the WP34s given any thought to the concept of hacking a 15C-le into an emulation of the 16C?
I've been thinking to do a KEMU port to the sam7 voyagers
for some time now. But my impasse is really wanting
to displace the segment display with a graphic matrix.
It is quite possible to do so as the lcd segment controller
drive is multiplexed as gpio. However a custom module of
either COG or COB topology is realistically required. COG
provides minimal vertical elevation but has problematic
active area asymmetry, has interconnect routing issues, and needs off-glass charge pump capacitors (which could be
located on a flex pc interconnect). COB can address routing and
charge pump components allowing use of a less expensive FFC
interconnect. But a conventional
COB unit is problematic due to available
z-axis consumed via pcb, zebras, and compression frame residing
in tandem to the glass. The frame and zebras can
be displaced by heat seal tape and in doing so we don't need
a particularly ridgid pcb. It might be possible to reduce it
to 0.4mm -- however the COB encapsulant projection
could double that.
Even dismissing all the above, it is still a custom glass
prospect to optimally fill the existing window and fit within
the existing glass enclosure void. I think the quote I had for
a near ideal 192x32 unit was somewhere in the US$7-8K ballpark
which included one-time tooling and delivery of the first 1K
units.
That's a tall order and travelling this path may not make
much sense unless leveraging it as an opportunity to
provide some sorely missing features. Eg, at a minimum:
external communication, high endurance NV memory, additional RWM,
perhaps external power.. Basically what I would have hoped for
in an encore voyager 30 years later, particularly a 15c.
Anyway this is all very much possible and straightforward
with with a new pcb layout. Doing so also allows the major
simplification of freeing us from the need to
shoehorn these enhancements into the existing design.
However at this point we get to
question whether the aged sam7 is worth the effort of bringing
forward given more cost effective and higher performance
SoCs currently available.
The one consideration which
(at least to me) prevents the above tirade from being wholesale
dismissed is the
fact such a prospective board+display swap on an encore voyager
is mechanically a fairly minor undertaking.
But I suppose from my POV I don't find a clear delineation in the
slippery slope continuum corresponding to a meaningful partial
feature set. At least that's my excuse for not having pursued
a physical prototype thus far.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Walter and I did discuss the possibility of re-purposing the 12c and decided it wasn't worth our efforts -- the segmented screen is too limiting being far worse than the 30b's which has always been quite an impediment.
- Pauli
Posts: 540
Threads: 22
Joined: Jan 2005
Quote:
Have any of you involved in the development of the WP34s given any thought to the concept of hacking a 15C-le into an emulation of the 16C?
If anyone's thinking about it, a couple of comments:
1) the 16C's maximum wordsize of 56 bits was huge for the time, but 64-bit processors are common now. I'm not sure how much of a practical limitation this is, but getting around it would be a huge job given the architectural platform;
2) the 16C uses the HP floating-point implementation of that era, rather than the now-ubiquitous IEEE 754(?) format (although the manual did provide conversion routines). An implementation of the IEEE format would be much more useful.
I'd say that an upgraded rewrite, rather than a straight port, would probably be easier, as well as more useful.
Best,
--- Les
[http://www.lesbell.com.au]
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The 16C allows a word size up to 64.
- Pauli
▼
Posts: 540
Threads: 22
Joined: Jan 2005
Quote:
The 16C allows a word size up to 64.
Yes - you're right. I've no idea why I'd got the idea the max was 56 bits. I've never used any WSIZE larger than 32 bits anyway, and the display made even that quite painful.
Best,
--- Les
[http://www.lesbell.com.au]
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The CPU registers are 56 bits perhaps?
- Pauli
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
The register size of the 16C varies with the configured word size and so does the number of available registers. In float mode, the word size is set to 56 bits but in integer mode, almost any word size up to 64 is legal. I haven't tried 1 though. It should be possible to configure the 16C to a single bit machine in unsigned mode (with a register size of 8, I assume.)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The internal CPU registers are 56 bits wide.
The calculator can be configured with any integer size from 1 to 64 bits. 1 bit works in signed modes too -- you get zero and something negative depending on the mode. In unsigned you get 0 and 1.
The actual memory used by registers is the next multiple of 4 up from the word size. Thus, 1 bit registers use 4 bits of memory.
- Pauli
▼
Posts: 540
Threads: 22
Joined: Jan 2005
Quote:
The actual memory used by registers is the next multiple of 4 up from the word size. Thus, 1 bit registers use 4 bits of memory.
Yep. Setting mine to 1-bit word size gives me 406 registers, equivalent to the 203 bytes available.
As to why I remembered 56-bit rather than 64-bit maximum word size, it beats me. Probably a recollection of the CPU register size.
Best,
--- Les
[http://www.lesbell.com.au]
Edited: 19 Dec 2011, 3:57 a.m.
Posts: 1,477
Threads: 71
Joined: Jan 2005
You probably got that idea becasue a 56-bit word size is the value set when switching back from floating point mode to integer mode.
Posts: 255
Threads: 22
Joined: May 2011
Speaking of which, does anyone have the details of the LCD and keyboard port mappings for the 12C+/15C LE?
A while ago there were rumours of a 12C+ SDK but I can find no further references.
Thanks...
Posts: 171
Threads: 15
Joined: Sep 2011
Hi David,
Have you seen this (if you haven't you will be amazed):
HP 1xC Voyager
Great way to combine 1xC Voyager series into one! I wonder if this would be possible using the new HP-12C+ ATMEL CPU with emulations instead of the KINOMI custom CPU.
Any thoughs?
Regards, Kerem
▼
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
I wonder if this would be possible using the new HP-12C+ ATMEL CPU with emulations instead of the KINOMI custom CPU.
The NUT cpu and Voyager system emulator in use (KEMU) isn't
tied to the KINOMI module in any way and the first prototype
was actually cobbled together around a Hitachi SH1. The
version of the KINOMI module shown in the demonstration used an
Atmel AVR atmega1284p SoC. This was largely due to the extreme
size restrictions imposed by the
14.0mm x 14.6mm footprint of the original NUT cpu lqfp package.
Otherwise far more hospitable SoC choices exist.
Porting KEMU to the HP-12C+ or 15c le is relatively straightforward.
But I'd be more interested to do so as part of a larger functional
upgrade to the encore voyager which frees us from the 7-segment
display, adds some form of external i/o to the device, and perhaps
extends available user memory (ideally as non-volatile).
▼
Posts: 134
Threads: 31
Joined: Oct 2011
Posts: 2,309
Threads: 116
Joined: Jun 2005
What LCD module are you using?
▼
Posts: 384
Threads: 18
Joined: Sep 2010
Quote:
What LCD module are you using?
I haven't found anything as standard product which I'd call even
remotely usable relative to either a NUT or sam7 voyager's
available display area. Given space constraints about the
only configuration option is a zebra or TAB-style interconnect,
as the asymmetry (or rather the glass extension for ITO/bump
interconnect) of COG rule it out. There are also other
unique requirements such as a straight reflective polarizer
and an aspect ratio in the range of 5:1 to 6:1 which pretty
much leave the empty set as far as COTS graphic devices.
Just satisfying the desired resolution, aspect ratio, and
polarizer pushes the problem to at least a semi-custom display.
Frankly concerning a graphic display upgrade, I'm undecided
whether a voyager retrofit is really the best use of time,
funds, and effort relative a new modified mechanical
design.
BTW on a semi-related subject, I didn't intend come across
as dismissing the openRPN effort in this regard.
However my personal experience with the above sends me
screaming into my pillow to witness a clean slate effort painting
itself into a corner, flirting with the headache of shoehorning
a display into an already defined enclosure footprint.
▼
Posts: 2,309
Threads: 116
Joined: Jun 2005
I was just interested in what LCDs you've used in your existing prototypes as shown in your videos.
Posts: 875
Threads: 37
Joined: Jul 2005
Quote:
Porting KEMU to the HP-12C+ or 15c le is relatively straightforward. But I'd be more interested to do so as part of a larger functional upgrade...
That is a laudible goal which would be greatly appreciated, but I'm sure a lot of people would be very, very happy with a straightforward port, if you should ever be so inclined.
▼
Posts: 170
Threads: 7
Joined: Apr 2009
it seems a good enough reason for the project would be to produce a bug-free set of firmware that can be reprogrammed into an unmodified 15C-LE set of hardware. and the 15C-LE already has a 'licence' (of sorts) to use the original 15C firmware image.
i'm quite sure if you could produce a firmware for the 15C-LE that was (say) 10x faster than an original 15C, drew just a couple of mA from the 2032 cells, and was 100% functional, then you would collect a great many new friends!!
|
