HP Forums

Full Version: HP-41 Synthetic Programming Conspiacy Theory
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I was thinking today (Yeah, dangerous, I know).

If we think back to the release of the HP-41C and how this was reported in PPC, it seems possible to me that HP lent a hand in the "discovery" if not the creation of synthetic programming.

Some time ago I thought I would re-read PPC articles just to see how HP-41C synthetic programming was discovered and developed. Imagine my surprise to find that quite detailed knowlege of it was evident right from the first review of the calculator.

As I think back to that time, it was a point when TI and HP were going hammer and tong (as were their users) to prove that they had the better calculator.

Calculator owners back then were pretty technically minded, a bit like the first computer owners, the first internet users, etc. What better way to attract them than provide a host of interesting and dangerous features? What better way to make them the subject of cult following by officially denying, if not their existance, certainly any support.

But did they REALLY deny support? It would have been quite easy for HP in one of their ROM revisions to make many of these synthetic functions (such as RCL c, or STO M) result in a NONEXISTANT error, but they didn't.

Some calculator bugs were fixed quite soon. But these were ones that could cause strange (and perhaps destrucive) behaviour in normally written code. These included the STO IND, and SF/CF IND bugs, and the non-decompiling when switching out of program mode. But those bugs that gave access to synthetic programming (Deleting program lines in CAT mode and strange key assignments were never touched.

So, I wonder.... Who was it who made the policy decision? Who in HP either briefed users as to what these instructions were, or who provided information in such a way as to allow its easy "discovery"?

Hmmmmmmmmmmmmm.....

Well, in the August 1979 issue of PPC, HP published (if my memory is correct) the HP41 Byte Table with a discussion of how functions were formed.

Surely, it must have occurred to some of our PPC forefathers that if these two bytes came together to form STO Y, then if they went down the line they might get other STO d type functions.

All that remained was finding out how to put the bytes together.

Also, since bug 2 allowed arbitrary storage of data into program registers (and more), strange functions showed up there too.

The most-fun bug, IMO, was the bug 3 allowing a SF IND 01 to turn on someone's BAT indicator. Quite fun for a high school student to do that to someone's HP41..."Darn it! I just put new batteries in this thing yesterday..." :-)

What I would like to know is how the SP pioneers discovered just WHAT those odd byte combinations did. Creating the combinations was a feat all by itself, but finding out the meaning of the new instructions is way more complicated.

Consider, for example, how they found out that register c had a '169' smack in the middle, and that messing with it was a sure-fire way to get MEMORY LOST. And this knowledge seems to have come really early in the game.

On the other hand, there were odd "catalogs" full of mysterious functions (remember eG0BEEP?) that were never fully understood.

If Richard Nelson or Roger Hill are lurking, how about commenting, pretty please?

-EM

I think discoveries like eGOBEEP were the "real" discoveries of synthetic programming.

The rest were pretty much known from the release of the first HP-41. Hence my initial posting.

Just out of curiosity, do you know if the HP-42S recognizes SP instructions? That machine was advertised as being able to run HP-41 programs. I have never as much as seen a 42, so I don't know from personal experience.

Regards,
-EM

The HP42S will recognize only a limited number of "synthetic" instructions.

By entering the Debugger on the 42S, you can actually type in the exact byte sequences that you want to construct any HP41 synthetic instruction.

Unfortunately, for most of them, the HP42S will reset them to "normal" type instructions when you exit the debugger.

What CAN you do synthetic-wise on the HP42S?

Well, one of the last issues of HPX devoted most of it's space to this topic. My memory is that you can make long labels LBL 'ThisIsAnExampleOfALongLabel' and other things, but nothing overly useful. No STO d, etc.

That's one reason why investigations into it on the 42s died off.

Gene

On early HP-42S revisions, you could change the 'speed constant' (or delay) to a different value.
This way the machine worked faster until the next shutdown.
On those machines, you could write a program to speed it up, and call it whenever you needed it. On newer machines, you had to change the value inside the memory browser by hand, and every time you needed it.

AFAIK, the program for changing the constant uses some kind of X<> IND xx with an illegal value for xx, which doesn't work on the newer machines.

Regards,

Raymond

What was the advantage of running the HP42S at anything slower than maximum speed?

Was this a way of HP equalising the performance of different machines or making sure they worked over the full temperature and voltage range?

Anybody know the instructions for speeding the HP42S up?

Here it is:

http://members.aol.com/hpgene/hp42fast.htm

Other useful stuff there too.

Gene

Would a speeded-up machine would take a hit in battery life, too? Perhaps HP chose a balance? Perhaps the test labs had a mother-in-law going, "That's too fast! Slow down!!"?