Re: 35s Anomalies

richwood wrote:

None I know of but I have not tried the 33s or pre 41C design HP LED
units.

I think we can safely assume that in no other HP calculator this "1" was
required before. <8)

I tried this on a original 20S, 41CV, 42s, 48SX, 48GX and 50G
calculators without error and with 1 both assumed and automatically
entered.

So does any calculator I ever used.

I remember though that the HP 67 and 97 allowed program data entry of
E 3 for example and the program interpreted it as 1000, saving 2
program steps.

That was a usual coding technique those days. Real nerds did the same on
a 41-series calculator which added the "1" automatically, removing the
leading 1 afterwards by means of synthetic programming (using the byte
grabber etc.). <8)

BTW - the 35s seems to add a leading zero before the decimal point even
if it was not entered. Key in ".1234" in program mode and "0.1234" is
stored. Well, not a big deal because it doesn't require additional
memory since each and every number now eats up 37 (thirty-seven) bytes
(!). I've already started using "Pi SGN" or "e IP" for small integers.
Even Clx e^x is faster than a plain 1. #-)

The 41C's compatibility software built into the card
reader had to take account of this in translating HP67 programs read
from HP67 magnetic cards .

In the 41-series any number fits on a single program line. Usually this
makes no difference to the classic (67/97/25/34/19/29/...) approach,
except in some special cases where parts of the number are skipped.
In such cases you could do tricks like this one:

x>0?
.
1
x

This divides x by 10 if it's greater than zero.

Of course the translation routines in the 82104A card reader were not so
sophisticated that they would virtually rewrite the 67-program to do the
same trick on the 41. In fact, the card reader's manual included an
addendum concerning these and similar cases where software from the
67/97 application pacs required manual adjustments by the user.

On my old Commodore LED RPN unit the 1 entry is required to even
enable exponent entry ;-)

One of the first things I wrote for my special data entry unit when I
started programming in Pascal was a routine that allowed entering values
in scientific notation without the need for an explicit 1 before the E.
<8)

Dieter

.

Relevant Pages

  • Re: Upgrading the ROM from SD card
    ... cluster boundaries), so you can fit more small files on a card with FAT32, ... but given the limitations of the calculator I can't see how anybody could ... I have no idea why the calculator defaults to FAT32 for 32MB+ cards. ... ofcourse we could use 1kiB sectors and use up ...
    (comp.sys.hp48)
  • Re: Infinite Try to Recover Memory loop [48GX]
    ... card connector); ... The calculator was working normally before my first fatal self-tests ... and before my second fatal self-tests. ...
    (comp.sys.hp48)
  • Re: Anyone interested in . . .
    ... JHM> can store external files which aren't HP objects at all, ... internal calculator use, ... The SD card is equivalent to an external hard drive, however, ... If the calculator stores anything onto the SD card, ...
    (comp.sys.hp48)
  • Re: New keyboard problem with new ROM
    ... > I update my calc from a 128 MB card just fine. ... FAT16 with 2KB clusters, there's a slight ... If I format it FAT32 with 512B ... for typical calculator uses I'd recommend the cheapest SD ...
    (comp.sys.hp48)
  • Re: built-in file copy chews my files
    ... You evidently mean, when you copy *computer* files to the SD card, ... outside of the calculator environment. ... an arbitrary computer file is stored in the calculator ... The string is the exact image, bit for bit, of the computer file, ...
    (comp.sys.hp48)