Dvb T V1 1 Firmware Sunplus Box Tv1 22
Aide Broeckel
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. Re: data sheets for Sunplus microcontrollers?
Message #4 Posted by Eric Smith on 12 June 2007, 1:51 p.m.,
in response to message #3 by DaveJ
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 and does ". Part of 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 oveMany 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 Re: data sheets for Sunplus microcontrollers?
Message #6 Posted by DaveJ on 13 June 2007, 5:58 p.m.,
in response to message #5 by Bill Wiese
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. ACT chip(was Re: data sheets for Sunplus microcontrollers?)
Message #10 Posted by Nelson M. Sicuro (Brazil) on 12 June 2007, 5:15 p.m.,
in response to message #1 by Eric Smith
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 Re: data sheets for Sunplus microcontrollers?
Message #11 Posted by Jeff on 18 June 2007, 10:06 a.m.,
in response to message #1 by 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.[ Return to Index Top of Index ]
I purchased a 35s this week and was shocked to find this five year old design is still on its original firmware. So I went looking for the means to flash the thing.The CPU, or microcontroller if you will, is an SPLB31A with 256K of ROM according to the Sunplus data sheet. There is no mention of how the software is loaded.Is it in fact the case that ROM in the SPLB31A means masked ROM? Thus updating the firmware requires creating new photo masks for the chip lithography?Thanks. Re: HP 35s - No Firmware Update?
Message #2 Posted by Paul Dale on 18 Apr 2012, 7:57 a.m.,
in response to message #1 by Stephen Panarelli
Quote:I wish it were possible to repurpose the 35s. Decent screen, good keyboard, lots of RAM, traditional looks. No exposed I/O but that is livable.FWIW that's a 4Mhz 8-bit architecture with 16-bit featuresforcibly hammered in sideways, the ability to peerat the 256MB ROM is restricted to 2x 16KB windows, and the bulkof the RWM dangles at the end of an anaemic 400KHz i2c bit-serial interconnect. The hardware managed stack is physically wiredand a maximum of 256 bytes.For all of the bad press the sam7 suffers here, I don't seethe Sunplus hodgepodge being preferable to a 32-bit linearaddress space ARM core capable of 36Mhz operation undersimilar conditions. While even power consumption relative toclock frequency appears to be a wash, the sam7 achieveshigher processing throughput. I suppose the SPLB31A must havebeen chosen by someone in purchasing rather than engineering.I can appreciate the benefit of a prospective wp34s port tosuch a device in terms of generalizing the codebase w/r/ta worst case target architecture challenge. But my personalexperience dealing with the contortions KEMU needed to navigaterelative to the substantially less radical AVR core, portingto the Sunplus wouldn't be my idea of a fun project.Concerning the 35s I've found its display to be quiteuninspired, essentially being an inflexible charactercell configuration with the concession of fully RWM-mappedpixels. The hp-42s did far better than that some 20 yearsearlier. HP 35s - total quality / display
Message #9 Posted by Martin Paech on 19 Apr 2012, 3:56 a.m.,
in response to message #8 by uhmgawa
Quote:Concerning the 35s I've found its display to be quiteuninspired, essentially being an inflexible charactercell configuration with the concession of fully RWM-mappedpixels. The hp-42s did far better than that some 20 yearsearlier.The HP-35s is really disappointing, especially the display (beside the catastrophic software). First notably from the typographic point of view the digits / characters have ill-favored proportions, they are much too high and have the wrong spacing, and---besides the reflective screen---the resolution is to low for a good readability, in particular of greek characters. Squarish 'pixels' should solve the first problem---and they free up space for a third display line.BTW there's a very nice technique for pure character-based displays, much better than 7x5 dot matrix elements (have a look at the brochure): -US/Default.aspxIn comparision to my every-day work-horse HP-15C from 1985---I give this masterpiece of 'engineering art' five stars in every category---the HP-35s gets four stars for the keyboard (five for the ENTER key!) and the color scheme [1], three stars for the general design of the casing (good: the rubber feets), at most two stars for its display and casing quality, and less than one for the (current) firmware and the processing speed (compared e.g. with the HP-15C LE).Martin[1] I give only three stars for the label font---the "Futura" is caused by HP's (IMHO) not very elegant corporate design. And it's very thoughtless or dilettantish for example to write the units "kg / lb" and "cm / in" correctly in lower-case letters but "KM / MILE" in capitals!Edited: 19 Apr 2012, 5:55 a.m. Re: HP 35s - display quality / e-ink
Message #10 Posted by Martin Paech on 19 Apr 2012, 7:44 a.m.,
in response to message #9 by Martin Paech