data sheets for Sunplus microcontrollers?

[Eric Smith]

Does anyone know where datasheets on the various Sunplus 6502-based microcontrollers (e.g., SPLB20D2, SPLB22A, SPLB30A, SPLB31A, as used in some HP calculators) can be found? They used to be on the Sunplus web site.

Sunplus seems to have fissioned into several companies, none of which seem to claim to offer those parts.

[J-F Garnier]

I found this from Generalplus company:
GPLB31A (pdf file).

J-F

[DaveJ]

It is a most puzzling choice indeed by HP.
It's not the worlds greatest micro, scalability to different products is limited, and it's an obscure brand so presumably 3rd party tools would not be nearly as mature, and supply longevity would have to be questionable. Although if it is truly 6502 compatible then that would solve the tool issue.

Perhaps the choice came down to price?

Anyone know if HP would code their calculators in C or assembler?

Dave.

[Eric Smith]

Yes, price. And Kinpo was already using it for that reason.

They write the software in C. The 6502 isn't a great choice for C code (or most compiled languages), so the object code size is fairly large.

[Eric Smith]

Thanks, that explains the mystery. That portion of Sunplus is now Generalplus, and the datasheets are available on their web page.

I'd still like to get the datasheet for the SPLB20D2, which appears to have been obsoleted by the GPLB20D3.

[Nelson M. Sicuro (Brazil)]

Speaking of CPUs, does anyone have specifications of the ACT chip from HP-97? Signal traces, cicles, states... My 97's ACT is dead (?), I'm thinking of a replacement using CPLD or a new microcontroller...

Thanks!

Nelson

[Bill Wiese]

Eric,

Various Sunplus controllers are 'nominally' 6502 compatible. It's been awhile, I'm betting there may be some but not all 65C02 instructions on board.

The lesser-capability Sunplus CPUs used in things like KBs and mice may lose a register (I think the .Y register) and associated instructions.

Bill Wiese

San Jose, CA

[Bill Wiese]

Quote:

---

It is a most puzzling choice indeed by HP.

---

That statement astounds me. Surely you know HP did not make the choice of CPU??

They went out and looked for calculator mfgrs with certain competencies and volume and pricing, and said, "we want a calc that looks like <this> and does <that>". Part of <that> would include power consumption/battery life considerations, and some measure of operational speed (PRGM mode instructions per second, max times for some of the more complex functions, etc.)

If Kinpo decided to use a (mythical) ultrafast 4-bitter HP wouldn't care. If, say, Kinpo decided that a VAX emulation layer was appropriate, fine - just as long as cost & power considerations are met. These level details are left to ODMs/OEMs now; HP buys a 'package'. High-level price/power/operational targets are all that matter between the 'name brand' and the ODM vendor. Most of the design in fact was done by Kinpo, with the 'styling'/arrangement/packaging 'feel' done by HP in cooperation with a product design house like IDEO or Frog-something or SmartDesign. (They do this for their inkjet printers, which they make a helluva lot more money from...)

Quote:

---

It's not the worlds greatest micro,

---

Again, who cares? Absolutely irrelevant.

BTW, in terms of volume shipped, 6502 derivatives are way up there. *Tons* of modems, tons of toys, etc. have 'em. Mitsubishi has their MELPS 37000/57000 8 and 16 bit versions (their 16 bitter is roughly like the 65C816 that was in the Apple IIc) that ran Nissan engine control computers in the mid thru very late 90s (and probably beyond) vehicles. Many many VCRs and TV sets and some microwave ove

Many chip selections are made not for architecture, but simply for pricing, availability, power consumption, I/O driving or even package choice - even if the chosen register/instruction set makes a programming task more difficult.

Quote:

---

scalability to different products is limited,

---

Again irrelevant? This is not an academic school project with grade based on how ultraportable code, etc. It's about getting the job done at minimum cost.

Many of these type of designs are treated as one-shot products with no intention of code reuse, update, etc. As it is, the coding for the calc is most likely in C so that's "portable enough". Any portability concern is more toward doing the same product on a new chip if there are supply concerns, than reusing the code base for a new, different product. As it stands, they could do an initial re-port over to an 8051 or 6805 or H8 design in a few days max.

Quote:

---

and it's an obscure brand so presumably 3rd party tools would not be nearly as mature, and supply longevity would have to be questionable.

---

Obscure? The fact you haven't heard of them doesn't mean they don't ship in volume. I imagine there's could be 100 - 500 million shipped products with varioous Sunplus chips in them, and that could be on the low side. Calculators, translators, alarm clocks, talking & automated toys, cheaper appliances, etc. all use Sunplus CPUs.

Supply longevity to get thru a sequence of production runs is good enough. No one cares about 2 years from now.

Quote:

---

Although if it is truly 6502 compatible then that would solve the tool issue. [/quite]

Again irrelevant. Any CPU vendor will supply tools to a volume customer. They either create the tools themselves or have a relationship with a tool provider (like HiTech, who makes C compilers for various micros) It's almost a given - C compiler, assembler, linker and (maybe) some sort of debugger or monitor. Otherwise you can't sell your chip. [Maybe JTAG support added on bigger chips.]

[quote]Perhaps the choice came down to price?

---

Dude, it ALWAYS comes down to price - sometimes prior working relationships help, as Kinpo and Sunplus (or Sunplus') successor have had an ongoing relationship for some years.

Quote:

---

Anyone know if HP would code their calculators in C or assembler?

---

HP doesn't code anything anymore for this kinda product. Kinpo would be doing the work. 99% chance it would mostly be in C - some startup code in assembly, maybe some optimized I/O driver stuff, although I know it could readily be done all in C. A 1MHz 65C02 can reliably even 100% *emulate* an HP41C calc at full speed or more. Perhaps there some optimized BCD math routines in assembler, but there's probably not that much reason for it.

Having just about everything in standard C (plus or minus a few compiler+architecture dependent features) pretty much means architectural considerations are moot.

Bill Wiese

San Jose, CA

[DaveJ]

Ok, that's a different ball game entirely then, I thought Kinpo only manufactured the product, but all design engineering and coding was done by HP. I was obviously wrong.

Thanks.
Dave.

[Eric Smith]

Unfortunately it turns out that the Generalplus data sheets basically only have a block diagram and electrical specs. They apparently have Programmer's Guides and User Guides, but they don't make them available online. Sigh.

[Jeff]

Does anyone know what CPU is used in the 12C Platinum 25th Anniversary edition?

Thanks.

[Eric Smith]

I think it is a Generalplus GPLB31A, but I haven't seen anything definitive.

The 12C Platinum was originally claimed to use the Sunplus SPLB20D2, but they had to increase the ROM size when they upgraded the 12C Platinum to new firmware based on the 17BII+ code base. They did not revise the data sheet.

The 12C Platinum Anniversary Edition and the 12C Prestige are believed to share the same electronics and firmware with the revised 12C Platinum.