HP Forums

Sorry if I missed it in the various 15C LE threads: Is there an official statement about the 15C Limited Edition? SC still lists my preorder at $94.99, but pulled the 15C LE from the product page.

Will it appear in 2011, or can I forget about the preorder.

Thanks.

I think we have all jumped the gun on this and ignored statements made by those who truly have meaningful knowledge of the inner workings at HP. Two weeks ago Tim Wessman made the statement:

Quote:

---

There is no 15c launched in Japan, or anywhere else.

---

To me that is about as official a statement concerning the status of an HP 15C Limited Edition as you are likely to get.

then, pray tell us how it featured in HP websites? assuming they were not the work of hackers.

furthermore, Samson has opened orders (and I placed an order)

Quote:

---

I think we have all jumped the gun on this and ignored statements made by those who truly have meaningful knowledge of the inner workings at HP.

---

Quote:

---

OTOH, since HP messed it up, it would be reasonable to tell us what went wrong, if there were plans to develop this calculator or if there are actually such plans.

---

;^)

-Seth

So that's what the monolith in 2001: A Space Odyssey really looks like !

Edited: 31 July 2011, 3:16 p.m.

Nope! Wrong dimensions: the monolith had a ratio of 1-4-9, far from voyagers' golden ratio... ;)

Greetings,
Massimo

I remember us speculating at that time in school: It's real dimensions are 1-4-9-16 d8-)

Walter

Sure! But, alas, not to our (poor) 3D senses...
Other worlds, others beings are waiting out there. ;)

Do sell a large print version of that? I'd love to hang it in my cube. :-)

TW

It's an iPhone 5 ...

Quote:

---

then, pray tell us how it featured in HP websites? assuming they were not the work of hackers.

---

Yeah, that's what I want to know. The "limited edition" Hp15 image came from hp's official website.

Quote:

---

Do sell a large print version of that? I'd love to hang it in my cube. :-)

TW

---

Nope, it's just a graphic I slapped together from two pictures stolen off the Internet :)

But here's a (slightly) larger version you can print out in the convenience of your own home or place of work:

http://www.loomcom.com/m/i_want_to_believe_15c_large.jpg

And the Monolith seemed to have a capacitive touchscreen or touchpanel; not a positive-feedback rotating-key actuator.

Careful what you hang in your cube, these things give ideas... :-)

Quote:

---

furthermore, Samson has opened orders (and I placed an order)

---

Excellent.

Not that this is a surprise in the least.

And to the tune of a Dire Straights classic: "I want my 15C"

- Pauli

Edited: 1 Aug 2011, 3:33 a.m.

pie in the sky? or Lucy in the Sky with Diamonds? ;-)

I don't think there will be a re-release, at least not this year.

There is still hope. it has not been removed from here.

:-)

Maybe I need to move to India.

Not necessarily! Look also here !!??

I find all this affaire very insteresting.

Edited: 1 Aug 2011, 12:17 p.m.

Let's try to get he "Like" counter on that page up in the many thousands, maybe HP will get the message that it's time to release this! :)

Quote:

---

Excellent.

Not that this is a surprise in the least.

And to the tune of a Dire Straights classic: "I want my 15C"

- Pauli

---

Here's a new vendor that has the lowest retail price I've seen so far ($76.29). It looks like they ship internationally.

www.digitalspyders.com

Mark Hardman

I saw that too. Shipping is a bit higher, $10 for FEDEX ground within the USA, although the cost doesn't change for added quantity. They also presumably take orders for the HP-12C 30th Anniversary. It will be interesting to see how long this vendor page stays up.

Quote:

---

Nope, it's just a graphic I slapped together from two pictures stolen off the Internet :)

But here's a (slightly) larger version you can print out in the convenience of your own home or place of work:

http://www.loomcom.com/m/i_want_to_believe_15c_large.jpg

---

That version doesn't show the "Limited Edition" graphic.

Quote:

---

That version doesn't show the "Limited Edition" graphic.

---

Quote:

---

I think we have all jumped the gun on this and ignored statements made by those who truly have meaningful knowledge of the inner workings at HP.

---

I think it was the resellers who jumped the gun.

Honestly, so many authorized resellers offering the same product all at once seems to me to rule out the possibility that the 15C LE doesn't exist. Clearly someone leaked the official photo, and the dealers felt they were released from their NDAs. (Such agreements often contain clauses stating that obligations end once the information is made public elsewhere.) Then, I'm guessing, HP got back to each of those dealers, and gently pointed out that they might not continue to be authorized resellers of they didn't pull the information and cease taking pre-orders.

The timing of the release may or may not have been affected by this fiasco, but the fact that a 15C rerelease product exists is confirmed, in my opinion.

Quote:

---

There is no 15c launched in Japan, or anywhere else.

---

Note present tense. (Emphasis added.)

Quote:

---

Quote:

---

There is no 15c launched in Japan, or anywhere else.

---

Note present tense. (Emphasis added.)

---

Quote:

---

What you emphasize looks like past tense to me, as a foreigner.

---

English makes no sense. :)

Launched can be present tense, "it is launched," past tense, "it was launched" or future, "it will be launched." The verb "to be" is carrying the tense. An implied "to be" is present tense, at least in this case.

I'm not enough of a language wonk to give you a detailed explanation, and the above may have errors, but that's how it works.

Edit: There is a "to be" verb in the sentence.

Quote:

---

There is no 15c launched in Japan, or anywhere else.

---

And "is" signifies present tense. I don't know if such a thing as "implied to be" exists. :) My former emphasis of launched was incorrect.

Edited: 1 Aug 2011, 8:11 p.m.

IIRC from my school days, there is a "present perfect tense" where a verb preceeding a past participle carries a past action into the present time. So if we say "launched", we are implying "HP has launched" in this case. It's like saying it's a fait accompli. It is a condition that is active in the present and carries forward to the future until we are told otherwise. So, I take TW's statement to mean "whoa boys, don't count yer chickens 'til they're hatched." Maybe there will be a HP-15C LE in the future, and maybe not. But, right now, regardless of what has been posted on the WWW, and regardless of how many orders have seemingly been placed, it's just like vaporware. Hopefully, it will all come to pass, but I'm not certain that it will, any more than I'm certain that the world economy is not reeling inexorably in a death spiral towards extinction.

Quote:

---

Here's a new vendor that has the lowest retail price I've seen so far ($76.29). It looks like they ship internationally.

www.digitalspyders.com

Mark Hardman

---

they don't do international sales. they have no clue on its availability either. here's their email to me:

Hi Sorry,

Don't know when this is coming in and no we don't ship internationally.

If you have a relative in the US, have them buy and ship it to you.

Thanks,

Sales Team
DIGITAL SPYDERS INC.
TF 877-289-2787
http://www.digitalspyders.com/

Quote:

---

Let's try to get he "Like" counter on that page up in the many thousands, maybe HP will get the message that it's time to release this! :)

---

Folks might find this interesting. It is a project I've had
on the back burner for some time. Although recently I fabricated
boards and built a prototype which is depicted here:

KINOMI Project

[Note you'll need to enable the YouTube closed captioning
feature to render the accompanying explanation. It is the
red "CC" button in the lower right of the video window.]

Where do we get one????

- Pauli

Who needs HP when there are folks like you out there.

You need HP for the shell and keys :-)

- Pauli

Yeah - where do we get a Kinomi module from ??

Hey, that's great work! Buy and carry one, get three free :-) Want to buy! (instead of a LE)

To Michael: We continue needing HP for the mechanical HW and basic electronics. This includes the famous keys. And it will - hopefully sometimes - include more versatile displays. HP, are you reading?

Walter

Quote:

---

since HP messed it up, it would be reasonable to tell us what went wrong, if there were plans to develop this calculator or if there are actually such plans.

---

It is NOT reasonable to expect HP, or any large company, to comment on unannounced products, even if there may have been some inadvertent release of information. HP doesn't *owe* us anything.

That said, HP has been much more forthcoming about providing information about their plans to the user community than they ever used to be. Old-timers will remember the famous "HP Blank Stare" that questions about unannounced products *always* elicited back then.

If a new product is in the works, we'll all find out about it when it is officially announced. Until then, don't expect anyone from HP to confirm or deny. As the Mission Impossible taped orders always stated, "...the secretary will disavow any knowledge...", or in the immortal words of Lao Tzu, "those who know do not speak, and those who speak do not know".

Quote:

---

Power

2 CR2032 batteries

---

Oh, the new 15C LE uses two batteries.

Same as 12C+

Quote:

---

Hey, that's great work! Buy and carry one, get three free :-) Want to buy! (instead of a LE)

---

The original motivation for the effort was experimental
with the goal of producing a minimal footprint NUT/Voyager
emulator, yielding competitive performance (emulation
speed, power consumption, new features) on contemporary
microcontrollers. I believe that has been achieved as the
KINOMI module demonstrated employs a commodity 8-bit flash
uC running at 8Mhz. The emulator is written in C without
(yet) any comprehensive code analysis nor optimization
outside of being carefully implemented for that execution
environment. That said it achieves a general throughput
of 5-6x over native when executing on an 8-bit uC running
at 8Mhz.

In minimalist form the core NUT/Voyager emulator is only about
8KB of code. In addition to this exists support for a serial
debug console, an ISA bus driver for interface to the LCD
controller, and in the version depicted logic to support
firmware selection between multiple images. The largest
component of the footprint is the actual Voyager/NUT
firmware which weighs in at 7.5~15KB per model. Even then
a single purpose 15C KINOMI module can be realized with a
$2 32KB flash microcontroller. The prototype demonstrated
including 11c/12c/15c/16c firmware has an overall footprint
of 52KB, with the entire emulator and associated support
code consuming only 14.5KB of that total.

Most of the module configurations thus far contain external
flash in the form of high endurance EEPROM (1e6 erase cycles)
such that user data can be retained indefinitely without
relying on the internal button cells. In addition to this
the module version demonstrated has an IRDA (optical)
interface allowing data to get in/out of the unit without a
physical connection. Getting this to fit in the 14x14.6mm
real estate void of the original 44-pin LQFP NUT was a
substantial challenge.

If there is sufficient interest, I may just release the
work as an open source project.

Thanks,

-john

Quote:

---

To Michael: We continue needing HP for the mechanical HW and basic electronics. This includes the famous keys. And it will - hopefully sometimes - include more versatile displays. HP, are you reading?

---

I have support (somewhere) for rendering to a 128x32 graphic
module which works out well using a 9x20 proportional font for
the main display and a 7x9 fixed font for the annunciators.
It also has the obvious benefit of freeing you from trying to
intelligently encode user interaction into 7 segments. But I
sense attempting such improvements may put the effort on a
slippery slope in terms of feature creep where you're departing
from the elegance of the original design.

The other more practical issue is I've never seen a suitable
graphic display which approached the contrast quality of the
low 2:1 multiplex rate segments used in the original voyagers,
although they were designed out from 1988.

Quote:

---

You need HP for the shell and keys :-)

---

Indeed, injection molding (particularly the double-shot
key legends) isn't at all cheap. Although CNC milling of
key blanks and perhaps even the shell may be feasible in
prototype quantities. 3D printing might get you part way
there but not an equal.

Incidentally, although HP long ago abandoned double-shot
molded key legends in favor of printing, from a repurposing
perspective they are more useful. The printed legend can be
buffed/polished off leaving a blank key. The blank can be
cnc engraved and filled with epoxy paint which will
effectively get you back to the service of double shot
molded keys. The blue g-shift key legends which were always
painted can also be redone as such.

The other issue is the keyboard and bottom legend plate.
I must be missing something as I'm unsure why HP is still
printing on top of an aluminum base. Using a bottom
printed polycarbonate label would be far more durable and
probably no more expensive even with a metalized layer
added as a static shield.

I am very interested in this kinomi project. It is a great work and I looked in awe.
After viewing the video, I would like to ask some quesrtions concerning this.

1.What kind of 8-bit µC did you use? Is it kind of BGA?

2.How did you mount the whole board onto the LQFP site?

Caould you post a bigger picture of it?
(I cannot see clearly in the video.)

3.How did you program the µC?

Thanks in advance.

By the way, I happen to find out the analogy between kinomi (木の実) and nuts.

(Of course, after consulting the dictionary.)

Best regards,

Edward CG

Quote:

---

The other issue is the keyboard and bottom legend plate.
I must be missing something as I'm unsure why HP is still
printing on top of an aluminum base. Using a bottom
printed polycarbonate label would be far more durable and
probably no more expensive even with a metalized layer
added as a static shield.

---

Quote:

---

I have support (somewhere) for rendering to a 128x32 graphic module which works out well using a 9x20 proportional font for the main display and a 7x9 fixed font for the annunciators. It also has the obvious benefit of freeing you from trying to intelligently encode user interaction into 7 segments. But I sense attempting such improvements may put the effort on a slippery slope in terms of feature creep where you're departing from the elegance of the original design.

---

Why? We experienced our WP 34S being severely limited by - among others - its low resolution LCD. A dot matrix as you mentioned would open a wealth of opportunities for an open-source calculator allowing softkeys and menus like the high end Pioneers did. And the Voyager package features a very attractive mechanical environment for such a project IMHO :-)

Of course, these are only my 20m€. YMMV

Walter

Quote:

---

And I agree the present KINOMI 4-in-1 model is so great it should be released.

---

While I think that this is an interesting project, like the other 15C-clone project won't HP assert its copyright over the ROM images used in the KINOMI project? I wouldn't fault them for doing so at all since they have the existing 12C+ and (apparently) soon to be released 15C+ using the same ROM images.

-Katie

Hey HP, are you considering a 16C+?

Quote:

---

While I think that this is an interesting project, like the other 15C-clone project..

---

Wow, I hadn't realized there was a related project underfoot.
I've been away from this forum too long. I suppose I'm
happy to have been ignorant of it until I finished the KINOMI
prototype otherwise it would still be collecting dust. :P

But this is a little bizarre as I'd considered using an LPC1114
and in fact have prototypes in development. However while fast,
it has a flash size limitation of 32KB precluding on-uC support
of multiple images. Locating the firmware in say an external
SPI flash, even with hardware assist, slows execution
dramatically and the emulator instruction fetch needs to
implement some sort of caching scheme which adds its own
overhead. Ask me how I know.

The specified current consumption for the LPC1114 is a factor
of 10 higher than any uC used in a KINOMI module when in its
respective lowest power-down mode retaining data in R/W memory.
Also for KINOMI use the voltage limit for an LPC1114 would
require a regulator to drop the 4.5V supply and potentially a
level translator to drive the ISA bus. Not too agreeable
within a 14x14.6mm module. However to be fair the attraction
of using a dirt cheap Cortex-M0 is so compelling that the
LPC1114 is still on my list for other configurations.

Quote:

---

won't HP assert its copyright over the ROM images used in the KINOMI project?

---

Personally I don't want to take on that argument with HP.
KINOMI doesn't have any relation to the legacy firmware
other than being able to execute the images faithfully,
and includes sufficient voyager emulation to support a
serial console, alternate (graphic) displays, keypad
scanning, ISA bus protocol driver, etc.. Voyager firmware
images are available from unauthorized sources, however I've
used images extracted from devices I own personally -- which
is why a 10C is missing from the lineup.

One use case for KINOMI was as a single model functional upgrade
(or repair) module for Voyagers. In that scenario a KINOMI could
be swapped for the NUT, and upon first boot extract the R2D2
rom image(s), self-programming them into it's on board flash.
Doing so we haven't distributed the originally purchased
firmware outside of the device so we shouldn't have any
concerns.

Quote:

---

I wouldn't fault them for doing so at all since they have the existing 12C+ and (apparently) soon to be released 15C+ using the same ROM images.

---

Personally and honestly I have a great deal of respect for
HP and in particular their engineering achievement in
these devices. This has been the primary motivation here.
Otherwise actually gainful use of my time exists invested
in other pursuits. However back when I started poking at
KINOMI, there was no promise of a reintroduced 15C/16C and
dealing with the near casualty cases on EEEbay at
mind-numbing prices was IMHO insane.

The prototype I've demonstrated is really just a proof
of concept device. I suppose it might be productizable in
some scenario, perhaps with key legend overlays but that
doesn't seem to have general appeal and I doubt it is going
to make anybody rich. It may be attractive to some as an
expermenter's device which is why I considered making it
an open project.

Thanks,

-john

Edited: 5 Aug 2011, 8:34 a.m.

Quote:

---

A dot matrix as you mentioned would open a wealth of opportunities for an open-source calculator allowing softkeys and menus like the high end Pioneers did. And the Voyager package features a very attractive mechanical environment for such a project IMHO :-)

---

Removing the segment display also gets rid of the R2D2 ISA
driver which, believe me, was somewhat of a haunted house
to drive reliably due to undocumented timing/logic quirks.

I was avoiding the need to cut the heat stakes for board
removal and found a way to extract a NUT lqfp without destroying
it nor cook the elastomer zebra strips on the other surface
of the board. However an LCD upgrade would require board removal
and honestly, resetting the ABS heat stakes isn't that horrendous.
What will trip up the effort though is finding a suitable graphic
display with the same window area as the original segment display.
And it needs to be a straight reflective (not transreflective)
device in order to avoid further reduction in contrast.
Reflective LCDs are quite rare off-the-shelf these days.

Once the main PCB is removed we have some flexibility to mill
the window area to a new footprint and perhaps replace the
aluminum bezel, but this is starting to approach the point of
diminishing returns. IOW we'd probably be better off to make
the actual enclosure needed.

Quote:

---

I am very interested in this kinomi project. It is a great work and I looked in awe.
After viewing the video, I would like to ask some quesrtions concerning this.

1.What kind of 8-bit µC did you use? Is it kind of BGA?

---

The packages are 0.5mm pitch MLF. The uCs used are either
an atmega328p (single image) or atmega1284p. However considering
the relatively small price difference and the fact the 1284p has
sufficient i/o ports to drive the key matrix directly, I don't see
any reason to continue on with the 328p. Especially as we gain
4x flash (128KB) and 8x SRAM (16KB) capacity with the 1284p.

Quote:

---

2.How did you mount the whole board onto the LQFP site?

---

The bottom side of the KINOMI pcb was needed for bypass
capacitors as I was out of top surface real estate and that
was the compromise of avoiding a 4 layer board. In order
to keep the vertical profile minimal and allow a FFC debug
connector on the module, the KINOMI board thickness was
reduced to 0.8mm and the bottom side components are all
0201 surface mount devices.

Adding on the IRDA transceiver bumped off even the FFC connector
so debug connection to that version of the module is accomplished
with plated vias in the board to which mates a custom connector
constructed from tempered stainless steel probes. This is not
as cumbersome as it sounds.

The bottom of the KINOMI board has land pads mating with those
on the Voyager main PCB. Connection is via copper standoffs
of 0.4mm diameter oriented with and sandwiched between each
set of mating pads. A layer of 0.05mm kapton tape acts as
a insulation guard between the bottom SMD and Voyager PCB
traces.

Quote:

---

Caould you post a bigger picture of it?
(I cannot see clearly in the video.)

---

Yes, I will put together something in a bit. It may just be
the schematics, gerbers and a few jpegs in an archive.

Quote:

---

3.How did you program the µC?

---

The uC was physically programmed with a avrdude running
on a linux box.

The emulator "KEMU" used in the project was written in C
as a linux application, and then ported to an SH1, SIMAVR (an
AVR core emulator), the m328p, and finally m1284p. The
SH1, SIMAVR and m328p ports probably no longer build and
are inconsequential at this point.

I would love to have avoided the AVR core 328p/1284p uCs.
But except for raw speed of the current Cortex-M0 devices,
the AVRs require far less power consumption (particularly
in power-down mode) and provide larger on-chip flash and RWM
in uCs offering these minimized power levels relative to ARM
counterparts.

Use of an 8-bit cpu as a C language target is amazing in
the fact gcc works as well as it does. But there are
numerous issues which manifest as code inefficiencies
which aren't or can't be optimised out. The harvard
architecture of the AVR core is also maddening when dealing
with storage of constant data in flash. But it is workable
with effort and I myself was amazed the KEMU core weighed in
under 8KB.

Quote:

---

Thanks in advance.

By the way, I happen to find out the analogy between kinomi (木の実) and nuts.

(Of course, after consulting the dictionary.)

---

;) Yes "kinomi" means "nut" in Japanese.

Thanks,

-john

Edited: 3 Aug 2011, 2:18 a.m.

Wow!! A fantastic project :-)

I had been thinking along the lines of using the 12C+ to re-make the 15C, just as everybody else here has;-).

My thoughts for a dedicated 15C:

• The code would have to be re-written to avoid HP copyright, else convince HP to allow free distribution for re-flashing 12C+'s, they'd be getting their money from those anyway.
• Eric Rechlin could make keyboard overlays, they would probably be easier to apply that the 20b/30b as the voyagers have a slight recess.
• Dallas Osborne has already made metal badges for voyagers, and could make 15C ones.
• Next challenge would be the keys. If they made the same as the original silver 12C platinum keyboard then perhaps replacement ones can be made. Assuming the insides of the 12C+ is the same as the platinum in the link above, they can be replaced quite easily and the PCB re-fastened with screws as demonstrated.
• the last but by no means least challenge would be the bezel. It would have to be cleaned of the gold lacquer and re-done with clear lacquer. Or make a gold (brass?) 15C badge and have our own "special gold edition" 15C?

Quote:

---

Wow!! A fantastic project :-)

I had been thinking along the lines of using the 12C+ to re-make the 15C, just as everybody else here has..

---

I didn't realize until a few days ago there was semi-credible
(+/-) evidence an encore 15C was looming from HP. Up to that
point I'd been picking up occasional 91sam7l 12Cs from EEEbay
with the intention of doing a KEMU port. I still may as with
128KB of flash multiple firmware images can be supported. The
problem however is battery backed RWM being limited to 2KB
which is a little tight although probably a 15C/16C/12C is
feasible.

It would have been be helpful if HP laid out the board for
a (depopulated) high endurance SPI EEPROM as that could have
been used as secondary storage for "swapped out" images.
EEPROM is useful in general to hold model image context and
lessen the reliance on residual battery energy to hold a near
brown-out power rail while the user fumbles with battery
replacement. An EEPROM could be grafted on but
the COB entombed in a blob of epoxy substantially frustrates
that option. Note the specified erasure wear limit for EEPROM
of interest is 1E6 cycles which is the same order of magnitude
as the cycle life of the keypad tactile dome switches.
Ironically the EEPROM would be the easier replacement of
the two.

One thought I had was to create a retrofit PCB in order to
address such issues as well as adding on perhaps an
IRDA/optical communication so the device isn't a closed
box. That's the one feature I feel the Voyagers have been
lacking but no one really can fault such a shortcoming in an
1981 design. ;)

Anyway if a 15C+ does surface in the form of a repackaged
12C+ it would be enough motivation to create an upgrade
board minimally including the above enhancements.

Quote:

---

My thoughts for a dedicated 15C:
[ul]

The code would have to be re-written to avoid HP copyright..

---

What code are you referring to? If that of the Voyager model
specific firmware, I don't think it would be realistic to
replicate given it has 30+ years of soak in a deployed product
and was originally blessed by William Kahan.

Edited: 3 Aug 2011, 11:34 a.m.

Quote:

---

Quote:

---

My thoughts for a dedicated 15C:

• The code would have to be re-written to avoid HP copyright..

---

What code are you referring to? If that of the Voyager model specific firmware, I don't think it would be realistic to replicate given it has 30+ years of soak in a deployed product and was originally blessed by William Kahan.

---

Quote:

---

I was referring to HP objecting to the use of the actual ROM image (see the "News" statement at the top of the Nonpareil page). However, they may even object to a re-implementation that exactly mimics the 15C.

---

That certainly seems to be grey area. I pinged Eric some time ago
on what may have transpired there but he was mum on the subject.

Realistically I don't think HP is going to call the cops on anyone
experimenting with firmware images which they legitimately own.
Beyond that I suspect you get to conduct a different kind of
experiment. I think crossing the line of selling the firmware
for profit in any scenario, will result in a thoroughly
unpleasant interaction with HP.

The DM-15C clone may well be the canary in the coal mine in
that respect unless HP dismisses that effort with a 15C
re-release some time soon.

Quote:

---

However, they may even object to a re-implementation that exactly mimics the 15C.

---

To me, the most interesting aspect of the 15C code is that it's probably without important bugs.

Quote:

---

To me, the most interesting aspect of the 15C code is that it's probably without important bugs.

---

Exactly. With someone like William Kahan overseeing the
numerical algorithm development and 30+ years of soak in
the hands of professional consumers, that's a pretty tough
effort to eclipse.

Although I've seen some interesting behavior of the 15C
firmware during the development of KEMU such as scenarios
where the subroutine stack is allowed to overflow. And
keycodes which aren't generated by the voyager key matrix
causing interesting things such as toggling between '.' <-> ','
modes, entering firmware self test, causing an unconditional
power-off. At one point I recall finding read accesses to
nonexistent memory however that could have been related to
a bug I was chasing in KEMU at the time.

In the 34S I've overcome the RAM limit by writing to the flash from within the firmware. The flash survives minimum 10,000 writes. That should be good for some context switches.

Quote:

---

An EEPROM could be grafted on but the COB entombed in a blob of epoxy substantially frustrates that option.

---

There are eight GPIO pins bought out from the processor in one of the non-populated headers. These could be used to support a serial EEPROM or some serial RAM to expand the capabilities of the device.

- Pauli

Quote:

---

The problem however is battery backed RWM being limited to 2KB which is a little tight although probably a 15C/16C/12C is feasible.

---

2kb is a many times more than any voyager has. The 15c has 64 registers (plus a few extras). The rest have half this. There should be space for all the voyagers with some to spare. The 34S firmware uses less than 100 bytes for system stuff -- a lot less in fact. (2048-100) / 7 = 278 voyager registers. Four models with 32 registers and one with 64 is 192 registers total. This leaves 86 for the stuff I glossed over about -- that is 17 registers for each model.

Take out the 10c and the space equation gets even better.

Of course, the effort to rework the emulator to use the available RAM efficiently is another matter entirely :-)

Finally, I'd be more than happy with a 12c/15c/16c combination. The 11c and 10c don't add any functionality beyond what these three have.

Any possibility of preserving the stack registers across mode changes?

- Pauli

Quote:

---

2kb is a many times more than any voyager has. The 15c has 64 registers (plus a few extras). The rest have half this. There should be space for all the voyagers with some to spare.

---

Other data exists in addition to that visible from the
user's application perspective. Even within a single
emulation scenario, CPU and hardware registers need to
be maintained which consumes additional memory. Eg: KEMU
currently uses 95 bytes per virtual NUT cpu context alone.

Requirements such as the host's runtime stack and overall
global state data are most conveniently located in RWM which
persists over power-down events. Add to that other optional
features such as the command line interface, etc.. and that
2K starts to get full pretty quick. For example the 4-model
build as demonstrated weighs in at:

/usr/bin/avr-size kemu_m1284p.elf

   text	   data	    bss	    dec	    hex	filename

  51322	    220	   2019	  53561	   d139	kemu_m1284p.elf

data+bss total already exceeds 2K and we still haven't
accounted for the host runtime stack. Some of this
can surely be steered into the 91sam7l's 4K volatile
RWM but not much.

Quote:

---

Of course, the effort to rework the emulator to use the available RAM efficiently is another matter entirely :-)

---

Footprint minimization was one of the primary motivations
for KEMU. And I'd say it is quite conservative in terms of
flash and RWM consumption. Actually with over half of the
flash currently unused in the m1284p 4-model build, there
is an opportunity to relax code reuse and introduce more
efficient special-purpose routines where warranted.
Reconfiguring-in features such as the disassembler is
another possibility.

I took a look at where the m328p build was, configured with
a single 15c model and dropping out the firmware select
logic:

/usr/bin/avr-size kemu_avr.elf

   text	   data	    bss	    dec	    hex	filename

  25779	    162	    726	  26667	   682b	kemu_avr.elf

That still includes CLI support, keypad scanner, and ISA
bus driver so you could easily bandsaw another 2~3KB off
that total depending upon interface requirements
leaving you with an excess of 8K to glue KEMU into
the intended application.

Quote:

---

Finally, I'd be more than happy with a 12c/15c/16c combination. The 11c and 10c don't add any functionality beyond what these three have.

---

I agree. The 11c was tossed into the mix only because I own
one and had a firmware image lying around. I can't think
of a reason to include the 10c other than for historical
completeness.

Quote:

---

Any possibility of preserving the stack registers across mode changes?

---

Maybe the demo didn't make that clear or perhaps the closed
captioning was problematic -- I myself had trouble getting
the caption text to render without the most recent Adobe
flash player.

Anyway each image is independent and persistent across firmware
re-selects and of course power off events. The entire memory
content, device state, and NUT virtual cpu context is maintained
for each model version. One generalization which is possible
given the current structure is supporting multiple
instances of each model subject to memory limitations. Eg:
allowing a number of independent 15c instances among which the
user could select as needed. This is really just a UI/packaging
issue as it otherwise should drop into the current
structure. On that note the presence of high endurance
EEPROM would be a natural location to contain "swapped out"
instances with the added benefit of being retained across
battery failures.

-john

The 34S manages with the stack in the 4kb of volatile RAM. It is written as a single event processing loop and thus the idle state doesn't require any return stack to return from.

We also found another 55 bytes of RAM in the LCD controller which can be used to store things that have to survive the on but idle state but not complete power off. Much of our user interface state has ended up here. It is copied to and from the 4kb of volatile RAM.

It is surprising how much stuff we moved from persistent RAM to volatile RAM.

Quote:

---

Anyway each image is independent and persistent across firmware
re-selects and of course power off events. The entire memory
content, device state, and NUT virtual cpu context is maintained
for each model version.

---

Oh well, it would have been nice :-(

- Pauli

Quote:

---

There are eight GPIO pins bought out from the processor in one of the non-populated headers. These could be used to support a serial EEPROM or some serial RAM to expand the capabilities of the device.

---

I don't see anything I'd call a header on the unit in front
of me. Did you rather mean depopulated 0603 devices, of
which there are several?

Incidentally was a schematic for this device ever included in
the developer's kit or otherwise made available? I didn't find
anything close in what I'd squirreled away about a year ago.

Thanks.

There was/is a schematic in the 20b's development kit.

The pads I was talking about are labelled J8 just below the big exoxy blob. The connection pin outs are also published. Both for the 20b.

I've not opened a new 12c but I was hoping there are similar inside but am probably wrong :-(

- Pauli

Edited: 4 Aug 2011, 1:50 a.m.

Quote:

---

Quote:

---

Anyway each image is independent and persistent across firmware
re-selects and of course power off events. The entire memory
content, device state, and NUT virtual cpu context is maintained
for each model version.

---

Oh well, it would have been nice :-(

---

Walter

Quote:

---

Oh well, it would have been nice :-(

---

I wouldn't outright discount at least a 12c/15c/16c version on the 91sam7l. Dropping the 11c will reclaim nearly 400 bytes which is probably sufficient or at least quite close. Otherwise some restructuring of the logic is needed to deal with prospective volatile state. For example the current KEMU implementation
leverages the simplification of being able to power-down at
arbitrary points during emulator execution.

Some packing may be possible in the NUT cpu context for idle images. Also the CLI and display decode buffer don't need to be persistent.

But I think saving idle images to EEPROM is conceptually
a preferable solution. Unfortunately it requires a
modification to the 91sam7l version. Somewhat ironic as
there is more than enough empty component side real estate
where an MLF EEPROM could have been placed.

Edited: 4 Aug 2011, 9:39 a.m. after one or more responses were posted

Pauli, you are talking about the 20b. The device in question is the 12C+ which is obviously different.

I've already mentioned it in this thread. You can always consider the on board flash memory as writable from within the firmware.

Quote:

---

I've already mentioned it in this thread. You can always consider the on board flash memory as writable from within the firmware.

---

Indeed it is. The difference is Atmel specifies the 91sam7l
flash with an endurance of 10K erase cycles where the eeprom
of interest has an endurance of 1M cycles (and about 20x
longer projected data retention.) Depending on intended write
frequency wearout could be a concern. Logistically
an external 8-pad MLF part reaching wearout is also much
more easily corrected vs. die eternally bonded to the pcb.
Even replacement of a 0.5mm pitch lqfp-128 pin version of the
91sam7l isn't a welcome task. If vacant space exists my
inclination would be to add an 8-pad MLF land prospectively to
the pcb for these collective reasons. If left depopulated it
isn't costing us anything.

Although my bias is to avoid feature creep, another option is
use of socketed transflash (micro SD) in SPI mode. Acceptable
voltage range may need to be accommodated and active current
consumption could be an issue. But the option of end user
demountable storage is quite compelling.