HP-35s New Moon Lander behavior

[KayBee]

Hi All,

I typed in the New Moon Lander by William F. Graves and it has no syntax errors reported. I execute L to launch it and it flashes through various messages, but does not do the 321 countdown mentioned in the instructions. Would someone be willing to upload a video (to YouTube or wherever is best) of launching the game from the beginning and what I should be seeing?

I am a huge fan of Lander games and bought the 35 just to play this. Also I did search for Mr. Graves Jr. in order to ask for more details.sbut had no luck locating him.

Thank you.

KB

[Joe Horn]

Do you have a link to the version of the program you keyed in? I'd hate to key in a version different from yours... or wrong program entirely. Thanks in advance!

[KayBee]

Yes Sir, thank you. From the museum here:
https://hpmuseum.org/software/35moonla.html

KB

[SlideRule]

Joe, try New Moon Lander for the HP 35S (AKA 35moonla).

BEST!
SlideRule

[Joe Horn]

Thanks, SlideRule, for the corrected link.

KayBee, I just keyed the program linked above into an HP 35s, and it works exactly as described in its documentation. See the section called "Instructions" just above the program listing.

The listing contains one typo:
M003 INSRUMENT
was intended by the author to be
M003 INSTRUMENT
... but that is not what's causing your problem. If your program shows the messages CHECK-FUEL and BURN-RATE during pauses, but then doesn't show the 3-2-1-0 countdown, you must have a typo in your calculator somewhere between M020 and M037.

C027 is shown as Rv, but is really R↓ ... just in case that's not obvious.

A video isn't necessary; the documentation fully describes how to run the program and what you should be seeing and how to interact with it while it's running.

Good luck finding your typo!

[ijabbott]

I also typed it in (including the correction for "INSRUMENT"). It worked, although all the checksums were wrong. I understand that is a known bug of the 35s.

[Kevin Braun]

Ok, thank you gents for typing it in.

Cheers,

KB

[Kevin Braun]

Hmmm, I don't see a typo. Is it possible that my issue is modal? Could I be in the wrong mode?

Thank you again.

KB

[Joe Horn]

(04-26-2019 12:08 AM)Kevin Braun Wrote:  Hmmm, I don't see a typo. Is it possible that my issue is modal? Could I be in the wrong mode?

I don't think so. Here's my next guess:

Go into program mode, press [GTO] [.] M019 [ENTER], then look at the top of the display. See the "EQN" annunciator? Now press the down-cursor key to advance to step M020. The "EQN" annunciator turns off. Now advance down all the way to M037, but stop after each key press and check the "EQN" annunciator. It should STAY OFF for ALL those steps between M020 and M037. Does it? If not, then delete that line and re-enter it NOT as an equation.

If that doesn't help, I'm all out of ideas.

[burkhard]

(04-20-2019 07:40 AM)ijabbott Wrote:  I also typed it in (including the correction for "INSRUMENT"). It worked, although all the checksums were wrong. I understand that is a known bug of the 35s.

I typed it in as well (had to look up the trick to specify Flag 10: ".0" ), and while the program seems to work, indeed the checksums are wrong compared to the printed material.

Can you (or someone) explain what you mean by checksums being wrong "is a known bug of the 35s" ? Does that mean our checksums wouldn't match either, i.e. they are diferent on every machine?

If it doesn't mean that, what are the proper checksums?

There's one more minor typo in the listing: for line M028 it says "X<>y", when it really means "x<>y", i.e. a simple x-y swap. The improper capital "X" could throw someone off.
Additionally, all those "x<>y" are of course simple x-y register swaps, not tests of inequality between x & y. That's probably apparent to anyone used to HP keystroke programming, but just in case...

[grsbanks]

(04-26-2019 01:37 PM)burkhard Wrote:  Can you (or someone) explain what you mean by checksums being wrong "is a known bug of the 35s" ? Does that mean our checksums wouldn't match either, i.e. they are diferent on every machine?

https://www.hpmuseum.org/cgi-sys/cgiwrap...ead=121069

[burkhard]

(04-26-2019 04:05 PM)grsbanks Wrote:  

(04-26-2019 01:37 PM)burkhard Wrote:  Can you (or someone) explain what you mean by checksums being wrong "is a known bug of the 35s" ? Does that mean our checksums wouldn't match either, i.e. they are diferent on every machine?

https://www.hpmuseum.org/cgi-sys/cgiwrap...ead=121069

Thanks, seems like a the checksum comes from a hidden roulette wheel program with 2^16 "checksum slots" for the ball to drop into. Super.

I so want to like this calculator, but such things drive me nuts. This has been in production for 12 years and some simple changes to the firmware would have fixed this and most of its other problems long ago (at least for the ones produced after that point).

The thread grsbanks supplied is from 2007. To not have a provision to implement running bug fixes is shameful. I'm not saying they needed to recall all the buggy ones (although that would have been nice), but when a bug is ID'd, it should be stamped out.

[Valentin Albillo]

.
Hi, burkhard:

(04-26-2019 05:49 PM)burkhard Wrote:  [...] seems like a the checksum comes from a hidden roulette wheel program with 2^16 "checksum slots" for the ball to drop into.

Yes, sort of.

Quote:I so want to like this calculator, but such things drive me nuts.

The HP35s is a nice calculator, potentially even very good, but it simply has too many flaws and bugs, which ultimately get on the nerves till the breaking point comes by and you simply can't stand it anymore.

That's what happened to me. I was very interested in the HP35s the moment I knew of its existence and then I was presented with one. Initially I was delighted with it and used a lot of free time to get to know it, even wrote a number of non-trivial programs for it (two of them were published somewhere). So far so good.

But then I began to be really annoyed with the preposterous function set and badly implemented capabilities, most specially the abysmal handling of complex numbers and operations, same for vectors, same for memory management, same for number bases other than 10, automatic renumbering that you had to fight against and which would create erroneous branching when and where you least expected it, etc, etc.

Then, in case that wasn't enough, there were lots and lots of bugs, some incredibly frustrating as the infamous checksums which were so poorly implemented that completely defeated the purpose (so you couldn't quickly check if the automatic renumbering had gone astray again) and rendered the feature useless, and many others which ultimately affected usability, from forcing you to lose all your programs to simply destroying your confidence in the results you were getting, matter of fact I found that I simply couldn't trust the machine.

Eventually, after getting endlessly frustrated by the former and mercilessly stung by the latter, I simply gave up. I stopped using it or writing any programs for it and so it actually resides in my collection, well cared for but utterly unused, and it will remain that way for the foreseeable future.

A real pity, it could've been a really great product if HP would have cared in the least.

V.
.

[mfleming]

(04-26-2019 08:56 PM)Valentin Albillo Wrote:  A real pity, it could've been a really great product if HP would have cared in the least.

V.

Complaints about the 35S bugs come up on a periodic basis and on one of the many iterations I remember Tim W. giving a reason why the code was not corrected by the HP team. IIRC code development was contracted out to a Chinese firm that delivered no documentation on completion, only sparsely comment source code. Commented in Chinese. I really should see if I can find that thread to confirm the details.

One might complain that HP didn't assign someone to master the source code so the bugs could be addressed. As an experiment, pick one of the reported errors in Claudio's long running newRPL thread and see if you can fix it. Be sure to strip the code of all comments first though. Record how long it takes you to find and fix the bug, including testing time. Multiply the resulting time it takes by the number of bugs. I suspect the answer will be pretty high.

Not a task I would volunteer for!
~Mark

[burkhard]

(04-27-2019 01:40 AM)mfleming Wrote:  Complaints about the 35S bugs come up on a periodic basis and on one of the many iterations I remember Tim W. giving a reason why the code was not corrected by the HP team. IIRC code development was contracted out to a Chinese firm that delivered no documentation on completion, only sparsely comment source code. Commented in Chinese.

Well, sure, and as an engineer myself I'm quite sympathetic to the engineers at HP who see the fruit of their labors out there with deficiencies that could have been easily fixed years ago if not for a very poorly-conceived business arrangement executed by HP management. Anything involving a lot of complicated software never comes out 100% bug-free on the first build... or even the tenth build. It's wholly unreasonable to expect that. There needs to be a means to roll out corrections during the product life cycle. You shouldn't continue to put out flawed product for years (this model entered production in 2007 and they are still making it with the same bugs!) when you know how to fix it. It only hurts your brand equity.

In today's global business environment, of course there are manufacturing and sometimes even design and development arrangements made between firms. At the end of the day, though, if your company name is on it, you cannot forsake a means of bug-correction during the normal product life-cycle. There needs to be a provision for occasional updates to fix problems. You can't just throw it over the wall and let somebody else turn the crank for 10 or 15 years and then make excuses about why it "can't" be fixed. Bullshit. If that is so, somebody at HP entered into a horrible business arrangement. I am very glad they did not take that approach with the Prime.

[Maximilian Hohmann]

Hello!

(04-30-2019 02:21 PM)burkhard Wrote:  There needs to be a means to roll out corrections during the product life cycle. You shouldn't continue to put out flawed product for years (this model entered production in 2007 and they are still making it with the same bugs!) when you know how to fix it. It only hurts your brand equity.

Yes maybe. But we have to keep in mind that this is a 50$ consumer product, not an expensive camera, car or an aeroplane. Keeping a team together which tracks and fixes the bugs and updates the software for future production runs would raise the cost of the product significantly. Probably more than the usual customer is willing to pay. And those "horrible bugs" are really just minor issues, otherwise they would not have gone through the acceptance procedure.

(04-30-2019 02:21 PM)burkhard Wrote:  It only hurts your brand equity.

I think right now that brand equity is hurt much more by those rattling plastic printers which carry the HP logo. Where customers soon find out that refilling the ink or toner will cost them more than the original puchase. If have heard a lot more complaints about that "crappy junk from HP" in the last few years than I have about HP calculators in 40 years!

Regards
Max

[burkhard]

(04-30-2019 02:54 PM)Maximilian Hohmann Wrote:  

(04-30-2019 02:21 PM)burkhard Wrote:  It only hurts your brand equity.

I think right now that brand equity is hurt much more by those rattling plastic printers which carry the HP logo. Where customers soon find out that refilling the ink or toner will cost them more than the original puchase. If have heard a lot more complaints about that "crappy junk from HP" in the last few years than I have about HP calculators in 40 years!

Vielleicht geht dieser Punkt an Sie. :-)

(i.e. touché ! )

[grsbanks]

How very formal and polite we are

[burkhard]

(04-30-2019 03:17 PM)grsbanks Wrote:  How very formal and polite we are

The nun who taught me my German 35 years ago made sure her pupils were always höflich.
Of course, that was the pre-internet days and things seem to be a little looser now.
Nonetheless, I stick to my roots, which includes the pre-1996 spellings and capitalizing "Du", "Dir", and "Dein" in written communication.

And I use a 35-year old calculator as well. It's almost like time has stopped at 1984. :-)

[mfleming]

(04-30-2019 02:21 PM)burkhard Wrote:  There needs to be a means to roll out corrections during the product life cycle. You shouldn't continue to put out flawed product for years (this model entered production in 2007 and they are still making it with the same bugs!) when you know how to fix it.

First, I'm entirely sympathetic to your point of view. A little history is in order though. In the early aughts following the Tech Crash, companies were laying off entire divisions and sending their jobs overseas to LCR's (Low Cost Regions). This transfer was driven by a cut-costs-or-die imperative, as many companies teetered on extinction. No one really had much experience outsourcing at such a scale, and an enormous number of mistakes were made. I managed to avoid getting laid off myself until early 2006, so I saw a lot of projects go bust and a number of responsible managers getting their heads handed to them as a result.

I'm therefore not surprised at this failure, nor that management at the time made the decision that they could live with the defects in order to generate the revenue needed to recoup investment. The company formerly known as Hewlett Packard was undergoing a good deal of acquisition and divestment during this period, and much of the old guard were being shown the door as company culture was rewritten to support the new business focus.

Personally, I'm happy the calculator division, small as it is today, still exists and still produces in-house content. It could all too easily have gone differently...

~Mark