35s program checksums

[MarkHaysHarris777]

(01-23-2015 02:14 PM)rprosperi Wrote:  Given the 35S role as the last RPN Calculator HP will make (thus HP-35 "bookends") it is particularly sad that early on, HP chose to not fix the problems, thus more and more 'bad' machines enter the market, making a recall (or whatever) even less likely due to the increasing liability.

I also am viewing the 35s as a 'bookend' to an era. But I decided to apply a little logic to the evidence. I mean, what is, is. The unit is selling. The unit is still being manufactured. The unit is being used for real work, and the unit is recognized as the most powerful programable exam calculator (at least in the United States). How can this be if its sooo buggy? Begs the question.

I also have been thinking about the pre-release testing. Did HP NOT send this unit out to professionals prior to release to have it tested? Sure looked that way (I was initially shocked). ... 'till I started looking a little closer. For what ever reasons HP had, nobody recalls a calculator unit that works well within design goals and engineering criteria, and continues to sell. The very fact that the unit was not pulled from the market (yet continues to be sold and used professionally) speaks volumes about whether the 'buggy' or 'flaky' nature of the unit is bonafide. Yes, it has a couple of minor annoyances, and one gotcha. As a matter of fact, it really only has *one* gotcha. WARNING: Do not put the unit into a tight loop without a stop or pse. DONT do THIS:
A001 LBL A
A002 GTO A001

That is a little like Daffy Duck's famous, "Don't ever push the purple button!"

If you put the unit into a tight loop (intended or not) you might not (and probably won't depending) be able to pull it back with anything short of removing its batteries for a time, and losing your work. This is not a bug. This is an inherent 'gotcha' with the 8502 interrupt mechanism, including the scan routine(s). This 'gotcha' existed all the way back to the 8502's little sisters, the 6510 and the 6502. If you put the 6502 into a tight loop on the VIC20 (from Commodore) you would indeed have to turn it off to get it back. (ask me how I know?)
So, DONT DO THAT ! Never push the purple button! This problem is on the bug-list as number (15) and because it can happen if a would-be programmer is not aware -- well it has a very negative (although undeserved) infamous perception.

I will have a more formal response to the bug-list a little later; still thinking through it, and I do want to be as complete as possible.

I will give you a little hint about the perceived checksum difficulty-- what constitutes the smallest program unit of execution on the 35s, and what are the limits in storage for checksum computation for a given set of labels over a given memory range? If a would-be programmer does not understand the rules of engagement, then the checksums cannot be used to their advantage. I'm still experimenting with this, but for now I am convinced that the checksum mechanism is working as designed.

Thanks for the encouragement.
Cheers