Post Reply 
35s program checksums
04-01-2015, 01:22 PM
Post: #21
RE: 35s program checksums
(01-23-2015 02:14 PM)rprosperi Wrote:  
(01-23-2015 05:59 AM)MarkHaysHarris777 Wrote:  Thank you for your candor, and for some hints moving forward. I am going to be diving into this a bit in a week or two when I can get my hands on a second unit. Without the second unit for control|compare|contrast it will not be possible to speculate further. I truly suspect that for *everyone* the bug is simply not understanding how the checksums are calculated and what the rules are. Once we iron that out and publish it on the site somewhere folks can have a better confidence in the length checksum system. I too agree its a pretty neat system.

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.

The problem really isn't that HP chose not to fix the problems. They signed a contract with Kinpo that forbids any changes to the ROM. HP doesn't own the code used in the 35s, Kinpo does.

Tom L

Tom L

People may say I'm inept but I consider myself to be totally ept.
Find all posts by this user
Quote this message in a reply
04-01-2015, 08:09 PM
Post: #22
RE: 35s program checksums
(04-01-2015 01:22 PM)toml_12953 Wrote:  The problem really isn't that HP chose not to fix the problems. They signed a contract with Kinpo that forbids any changes to the ROM. HP doesn't own the code used in the 35s, Kinpo does.
There are several stories about this. If I'm not mistaken, one HP engineer has had a look at the machine code and commented it was to difficult to work on it (source was likely Assembler, as one member speculated after disassembling the emulator code).

I take it as a fact that there were contracts to develop the 33s, to fix some bugs and finally to develop the 35s firmware based on this code (both machines share some bugs). If all this was possible, there should be a way to contact Kinpo again about fixing the known bugs.

Likely, the 35s sells too well. But hey, there are no true bugs ... all just glitches and misunderstandings ... *rolleyes* Wink
Find all posts by this user
Quote this message in a reply
04-02-2015, 01:26 PM
Post: #23
RE: 35s program checksums
(04-01-2015 08:09 PM)Thomas Radtke Wrote:  There are several stories about this. If I'm not mistaken, one HP engineer has had a look at the machine code and commented it was to difficult to work on it (source was likely Assembler, as one member speculated after disassembling the emulator code).

I don't buy that. The 65xx series was the most popular CPU of its day. KIM, PET, Apple, Commodore 64, all used its assembly language. Most people who coded in assembly were familiar with the 65xx instruction set. That chip sold far more than any other, 8080A and Z-80 included. Yes, Intel chips have eclipsed them but how many programmers today use assembly on the AMD64 or x86 platform? The pool of knowledgeable 65xx programmers is still probably larger than most other groups.

Tom L

Tom L

People may say I'm inept but I consider myself to be totally ept.
Find all posts by this user
Quote this message in a reply
04-02-2015, 05:11 PM
Post: #24
RE: 35s program checksums
I was quite fluent in 6502 assembler (C64, of course-the beautiful ratmon still makes me smile Big Grin), but wouldn't touch it anymore, especially not for debugging other peoples code.

I'd leave this up to Kinpo or, even better, reimplement the firmware in C.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)