|Re: Saturn Specs|
Message #11 Posted by Vieira, Luiz C. (Brazil) on 17 Dec 2002, 1:02 p.m.,
in response to message #10 by glynn
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. ;-)