Saturn Specs



#13

Hi, everybody.

Does anyone know where to find Saturn internals (specs)? I want to know about registers, units, external connections and pinout... whatever exists. As it is obsolete, I think this is not such a secret, right?

Also the instructions and their descriptions: opcodes, parameters, flags, etc.

Is is possible? Do these info exist and are available?

Any info is appreciated. If you think it's easier, please, feel free sending any information directly to my e-box.

Thanks.


#14

The only public available and downloadable file is SASM.DOC from the HPTOOLS package. But this file only describes some software parts of the Saturn CPU.

Another sold document is the HP71 HDS, Part Number 00071-90071, it's the hardware internal design specification of the HP71.

All other internal documents to other HP chips are AFAIK not available.

Christoph


#15

Hi,

the IDS should be on the Museum's CD's.

And there are many related documents on www.hpcalc.org .

Regards,

Raymond

#16

There are two aspects to a processor design: the software architecture and the hardware interface. The former refers to the way the processor is programmed. Essentially what happens if the processor tries to interpret an opcode and 0 or more arguments. The latter refers to the connections between the processor and the outside world. Among many other things it tells you, how many pins there are on the processor and what each one of them issupposed to do.

Other info includes processor reset (what to do to ensure that the processor IPLs successfully after a reboot or power cycling), timing diagrams, state diagrams, etc.

If you want to write an emulator you need the software architecture, if you want to design a plug-compatible CPU, or to use a Saturn CPU in your project, you need both documents.

**vp


#17

Man, you got it.

It's difficult to do sillent movments when good ears sudrround you.

Yes, I have some ideas in mind. I'm more to HW than to SW. I believe PC emulators are good, but tactile feeling is a must when you have a portable computing device. And a customized keyboard is a lot better then a QWERTY palm.

I wrote something in here a few days ago and it called my own attention for this fact: morph translator. there are many available microcontrollers that are a lot faster than previous HP custom processors, Saturn included. A translating layer, a lot of memory, a fast microcontroler, keyboard and LCD driver... Oh, yes, the new HP calculators are based on this design, right? As posted here, those Citizen machines (SRP400G included) are something like this. What HP is probably doing is to add a translating SW layer, so they can emulate any HP former design. Even an HP48. Why not an HP42?

Just reasoning about...

Cheers.


#18

LOL, Viera!!

I got this mental image of Luiz as Ninja, dressed in black, avenging the death of his beloved calculators... stealthy as the wind...

Actually, this might just *SCARE* HP into developing more RPN calcs, if only for their own safety. ;-D


#19

(????????)

Sorry, Glynn... I didn't get it.

What's the point?


#20

Sorry, Luis--

Just a reaction by me to something that struck me as funny, the picture painted by your phrase about doing something silently. Ninja warriors in feudal Japan were supposed to be able to sneak up silently on their enemies (and invisibly too). Japanese movies and a barrage of spinoff pop-cultural references made this American visualize your quest in those terms. I of course forgot that many others would be scratching their heads and wondering what was the point. No point-- I had just let myself be tickled by a fancy.


#21

Well, what I meant as a silent moviment was probably from HP, not me. I was just reasoning about Vassilis answer under design, my own ideas, and what would HP be "silently" doing. Have you been reading previous posts where Dave mentioned HP asked him to send some manuals to their OEM in China? Also about Citizen specs and (I do not remember who) todays uP and calculators? There are Citizen calculators with the same features HP9G and 9S have, but other Citizen models (SRP400G - SRP? Slide Rule Programmable - Graphics?) are a lot more powerfull, and they are essentialy uControler-based calcualtors (these uControlers are used for industrial applications and can address 128K RAM). That's what new calculators are: powerfull, speedy controllers, with a lot of memory. I just joined all these data togheter with Vassilis' words, which led me to last post: just reasoning about.

That's why I did not understand what was I doing dreesed as Ninja. I thought Chinese HP designers would be dressed as well... but Ninjas are Japanese warroirs, right? Or chinese? Or Hewpackenese? Gee...


#22

Luis;

Just a thought about translating layers and morphing code and so on.

I would rather, if *I* were doing an RPN calc, collect a few programmers who knew the microcontroller in my proven design (SRP4000) by heart. I would send them specs and operational detail of what I wanted it to do. And then I would make sure they had any/every resource to understand the programming task they were responsible for. And I would let them code-- without them ever seeing, possessing, emulating, or understanding the Saturn.

You see, the code developed for the Saturn was GOOD-- for the Saturn. But its not the code itself that is necessary for a good RPN implementation. It is instead the craft of the programmers to give the overall product the excellence in user interface, the precision and reliability (code which causes the CPU to have to be reset is NOT good code), and the full utility of the product.

The only reason you would EVER want to do this via an emulation layer or by some intermediate code-translation engine is to maintain code-compatibility-- for the USER. Code internal to the calculator itself is not sacrosanct, nor is it optimal. Native implementations would almost always prove superior.

All you REALLY have to have are programmers who approach their responsibilities as carefully and as creatively as the ones of bygone yore. And I daresay that if you are working for HP you will probably find them, whether they are in Taiwan or Tampa or Trinidad.

What, of the Saturn-based code, can you use? If they developed the SRP4000, they ALREADY know how to eke out sins and antilogs and matrices and some kind of solver and probably have a library of code that can do math to darn near any precision the client specifies. They know the timing and the tolerances and the inputs and outputs and interrupts... of THEIR machine, not of the Saturn. What, then, IS the difference they need to code? The user interaction. Not being a function of the internal hardware, not the CPU at all, it makes sense to teach and describe the RPN behavior you are aiming for, and let them create a code-set of their own that meshes like the gears in a fine watch to the math and housekeeping code they have already tuned.

Do Taiwanese programmers know of RPN? Shoot, I bet a few of them have had 16c's on their desks since they got out of high-school. And most anybody working as a programmer has an intuitive sense of stack-manipulation and its workings. So I imagine a building-full of Chinese programmers that have probably just been salivating for the chance to implement an RPN SRP4000; waiting for their boss to say, go for it.

Now, WE, the users, are more likely than HP or anybody else to be tied to "Saturn Code". Why? Because it would mean compatibility with old user routines, old calculators and old peripherals and modules and card-readers and such (and maybe let us old users be more expert at the beginning). But HP has a HISTORY of remaking the background scenery-- in their image, not ours. Synthetic programming a la '41 is a hack, frankly, that HP neither intended nor condoned (it was a freight train they hopped once it was rolling, both because to stop it would have angered the user-base AND because they realized the cachet of power given the 41-- that it would go where no calc had gone before.) In designing a new calculator (or SERIES) HP probably would have any extension to the system come from, and be specifically enumerated and sanctioned by: HP. It's pretty certain they would love a whole bunch of development around the new calc. But only if it was user code that used specific, Legal, ways into and out of the system: nothing as unruly as entry via flaws in the internal code. HP had the ACO's 48 and 49 to teach them what could be done with an "open" system; their response, I think, to the TI's open systems and off-the-shelf processors. But as this new series is not likely aimed at the market represented by former 48 and 49 owners, if it WILL be "open", it will be with an "approved" entry-mode, a built-in assembler or such. (Don't count on it though: I think HP feels its product will in essence supply all a user could ever need directly from the keyboard or via menu.)

So. The Taiwanese calculator-factory programmers know controller code. They know math. They know RPN. They will have learned by now just what HP has in mind. They will implement it in ENTIRELY NEW CODE. It will be good, very good; or HP will find another offshore venture to invest in.

Why would HP contact Dave Hicks for old documentation? The answer is obvious, IF you assume the programmers already have working models by now and the rest of the factory are in the process of tooling up. I have the feeling we shall be seeing paragraphs of the old and familiar instructional stuff accompany the new product. That is my guess, Luiz, and under the assumption, of course, that Dave hasn't been keeping algorithms of internal stack flow for i-matrix transformation under his bed, so much as USER books and USER-orientation materiel that can teach a manuals writer what really needs to be communicated to a new calculator owner.

Now, we STILL need a Ninja Warrior, to make certain they lay out the keyboard right for RPNing, and use colors with decent contrast and in any shade but freakin' TEAL. ;-)


#23

This is not an answer to Glynn, just my addings. As the original text is a bit long, I preferred to reproduce it in my post (it's lone, now; sorry...). I know this subject has many times been part of long threads, and almost nothing changes. But it is always good to keep this matter alive. My primary interest on Saturn documentation was to be acquainted with technology I just briefly read about. I want to make sure I can comment about Saturn technology in a knowledge basis, not in artificial guesses.

"I would rather, if *I* were doing an RPN calc, collect a few programmers who knew the microcontroller in my proven design (SRP4000) by heart. I would send them specs and operational detail of what I wanted it to do. And then I would make sure they had any/every resource to understand the programming task they were responsible for. And I would let them code-- without them ever seeing, possessing, emulating, or understanding the Saturn."

I think this is a better way, too.

"You see, the code developed for the Saturn was GOOD-- for the Saturn. But its not the code itself that is necessary for a good RPN implementation. It is instead the craft of the programmers to give the overall product the excellence in user interface, the precision and reliability (code which causes the CPU to have to be reset is NOT good code), and the full utility of the product. "

The best code is the one implemented for the system, not necessarily an "imported" code, I agree.

"The only reason you would EVER want to do this via an emulation layer or by some intermediate code-translation engine is to maintain code-compatibility-- for the USER. Code internal to the calculator itself is not sacrosanct, nor is it optimal. Native implementations would almost always prove superior.

All you REALLY have to have are programmers who approach their responsibilities as carefully and as creatively as the ones of bygone yore. And I daresay that if you are working for HP you will probably find them, whether they are in Taiwan or Tampa or Trinidad. "

I think the issue here is not specifically the code itself. We know it works, we know it has gaps, but I feel as a matter of time. Why do we see many programmers uploading internal HP41, HP42 and HP48 code so they can be emulated? This is a Saturn strictly related code. Why not to develop, than, a code for the PC so it runs HP41, HP42 and HP48 with internal Intel code? A matter of time.

"What, of the Saturn-based code, can you use? If they developed the SRP4000, they ALREADY know how to eke out sins and antilogs and matrices and some kind of solver and probably have a library of code that can do math to darn near any precision the client specifies. They know the timing and the tolerances and the inputs and outputs and interrupts... of THEIR machine, not of the Saturn. What, then, IS the difference they need to code? The user interaction. Not being a function of the internal hardware, not the CPU at all, it makes sense to teach and describe the RPN behavior you are aiming for, and let them create a code-set of their own that meshes like the gears in a fine watch to the math and housekeeping code they have already tuned. "

You're completely right, source code for high-level and transcendental math is not "necessarily" written with an specific processor in mind, unless it already has internal floating-point capability. Inner system operation will not change, just user interface. And it's a high-level code.

"Do Taiwanese programmers know of RPN? Shoot, I bet a few of them have had 16c's on their desks since they got out of high-school. And most anybody working as a programmer has an intuitive sense of stack-manipulation and its workings. So I imagine a building-full of Chinese programmers that have probably just been salivating for the chance to implement an RPN SRP4000; waiting for their boss to say, go for it. "

"Now, WE, the users, are more likely than HP or anybody else to be tied to "Saturn Code". Why? Because it would mean compatibility with old user routines, old calculators and old peripherals and modules and card-readers and such (and maybe let us old users be more expert at the beginning). But HP has a HISTORY of remaking the background scenery-- in their image, not ours. Synthetic programming a la '41 is a hack, frankly, that HP neither intended nor condoned (it was a freight train they hopped once it was rolling, both because to stop it would have angered the user-base AND because they realized the cachet of power given the 41-- that it would go where no calc had gone before.) In designing a new calculator (or SERIES) HP probably would have any extension to the system come from, and be specifically enumerated and sanctioned by: HP. It's pretty certain they would love a whole bunch of development around the new calc. But only if it was user code that used specific, Legal, ways into and out of the system: nothing as unruly as entry via flaws in the internal code. HP had the ACO's 48 and 49 to teach them what could be done with an "open" system; their response, I think, to the TI's open systems and off-the-shelf processors. But as this new series is not likely aimed at the market represented by former 48 and 49 owners, if it WILL be "open", it will be with an "approved" entry-mode, a built-in assembler or such. (Don't count on it though: I think HP feels its product will in essence supply all a user could ever need directly from the keyboard or via menu.) "

I do not think this way. HP broke the chain with the HP28C: a new paradigm. What happened? Many kept previous RPN, others supported only RPL and some (me included) use both as well, no matter which, just a matter of the kind of problem to demand what. HP did not support this turn except for a few docs and a translating HP48 card, with limited capability, that allows HP41 programs (plain 41) to run in an HP48. Hrast gave us the true emulators, with very Saturn code. In a Saturn environment. But old calculators, peripheral devices and even an HP patented serial connection - Interface Loop - was disregarded in the new system; instead, RS232, recursive programming, multilevel stack... things some hate, some love.

"So. The Taiwanese calculator-factory programmers know controller code. They know math. They know RPN. They will have learned by now just what HP has in mind. They will implement it in ENTIRELY NEW CODE. It will be good, very good; or HP will find another offshore venture to invest in.

Why would HP contact Dave Hicks for old documentation? The answer is obvious, IF you assume the programmers already have working models by now and the rest of the factory are in the process of tooling up. I have the feeling we shall be seeing paragraphs of the old and familiar instructional stuff accompany the new product. That is my guess, Luiz, and under the assumption, of course, that Dave hasn't been keeping algorithms of internal stack flow for i-matrix transformation under his bed, so much as USER books and USER-orientation materiel that can teach a manuals writer what really needs to be communicated to a new calculator owner".

That's another point I would really like to understand: have the documentation been sent to R&D or OEM? Who is in charge to developing documentation? Engineers? Writers? Same staff? I'd like to know if these docs were sent to the guys that will rewrite them or read them.

"Now, we STILL need a Ninja Warrior, to make certain they lay out the keyboard right for RPNing, and use colors with decent contrast and in any shade but freakin' TEAL. ;-)"

I'm not suited to wear a Ninja dressing... but I'm flattered with the invitation. ;-)

#24

Hi;

as this thread is about to disappear, I'd like to thank you all who answered my request also through my e-mail.

Please, if there is any other information, I'd be glad having it.

Thank you, guys.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Saturn on Android_OS and i-OS CompSystems 6 530 03-17-2013, 01:40 PM
Last Post: hugh steers
  Saturn based emulators for android Olivier De Smet 16 909 07-29-2012, 01:32 PM
Last Post: Hans-Erik Lehndal
  HP-15C LE box specs for SC please! Juergen Rodenkirchen 5 425 09-12-2011, 11:16 PM
Last Post: Michael de Estrada
  Need technical specs for HP 17b calculator display Ken H 4 388 08-22-2011, 11:07 PM
Last Post: Ken H
  A lecture about the HP28 and the Saturn processor DaveJ 0 199 06-28-2008, 02:01 AM
Last Post: DaveJ
  82240 Printer Specs Joe Avins 2 248 04-07-2007, 04:17 PM
Last Post: Joe
  Saturn compatibility HP49G+ #2.00 ROM Christoph Giesselink 13 817 05-23-2005, 12:17 AM
Last Post: Ed Look
  MLDL2000 new specs and manual Meindert Kuipers 4 368 02-04-2005, 04:58 AM
Last Post: Diego Diaz
  HP-42S Saturn Address lines? Nelson M. Sicuro (Brazil) 3 299 07-21-2004, 07:30 AM
Last Post: Nelson M. Sicuro (Brazil)
  saturn processor pin assigment Mauricio Jaramillo 1 193 07-02-2004, 09:08 AM
Last Post: Bram

Forum Jump: