HP Forums
has 16C memory increased? - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: has 16C memory increased? (/thread-193314.html)

has 16C memory increased? - designnut - 09-05-2011

As I recall iot was a little short of programmable memory space.
I am unable to find if that has changed, anyone know? Sam

Re: has 16C memory increased? - Eric Smith - 09-05-2011

The 16C has been discontinued since 1988, so none of its specifications have changed since then.

If you are referring to the new 15c limited edition, AFAIK the only specifications that are changed are the speed (much faster) and the batteries (two CR2032, vs. three 357 button cells). The available memory is unchanged: up to 65 registers or 448 program steps.

Re: has 15C memory increased? - kc - 09-06-2011

So that's the question: Isn't it much easier nowadays to have say, 32k RAM than to have less than 2k?

Re: has 15C memory increased? - Paul Dale - 09-06-2011

The CPU in the modern 12c and almost certainly the 15c has exactly 2kb of battery backed RAM. So, no it isn't always easier to have more RAM.

The 15c firmware uses less than this BTW.

- Pauli

Re: has 15C memory increased? - uhmgawa - 09-06-2011

So that's the question: Isn't it much easier nowadays to have say, 32k RAM than to have less than 2k?

It depends on the SoC and whatever other functionality is competing
for finite silicon real estate. Most notably the current ARM
SoCs have rather limited RWM capacities. Also the lowest achievable
system power reduction in which RWM data is retained differs
considerably between designs. The power-down-data-retained
leakage current varying in proportion to the RWM size is another
motivation to limit its size.

Unfortunately with present SoCs applicable to this application
area you are limited to on-die ROM/RWM in practical terms for
direct access/execute memory. However for firmware emulator
applications, serial interconnect (eg: SPI) RWM can be
acceptable for firmware (vs. emulator) sourced access without
much of a performance penalty. To a lesser extent this can be
true for ROM (flash) as well but in my experiments I've found
some internal caching was needed to avoid getting bogged
down in SPI addressing overhead as well leverage repetitive
localized instruction fetching. To frustrate matters caching
itself consumes internal SRAM so an application specific
balance needs to be struck.