Great your older brother from me. He was our tutor during his military service at st Cyr.
I myself had an hp48 during my high school and now I own 6 of them I bought on Leboncoin or eBay for cheap. Also found an hp32sII for 5 euros but after three years I own it it decided to die in my hand.
Most of the models seems to age well except for the rubber-like connector between the key plane and the motherboard, and the keys are either not registering presses or you have to press hard on the body.
I don't remember exactly, have to look it up. I think it was a 48GX. But the problem is sending electronic items to the US is a real PITA. I'm in Europe myself. We shipped a MacBook with work one day from the US to EU and it would have cost us more than the thing was worth in import and brokerage charges, it was ridiculous :( In the end we had to decline and the thing went back but it still incurred a lot of charges there.
Ah the UK is also a problem now unfortunately :( Thanks to Brexit. But sending to France might be doable if that could work (I'm Dutch, in Spain). I'll have a look for it and ping you.
I’m looking for memory card either diy or genuine. Do you know if it exists anymore ? I often find custom Ron card with specific application (EE or advanced physics) but I cannot find 1mb black card for sell.
Blast from the past for sure, OP was not but I was in Paris in the early 90s, and HP48 hacking was huge. I remember attending class, ignoring the teacher, and just patiently leafing through long print outs of HP48 disassembly, or typing in assembler programs on the calculator itself.
The software on this thing was pretty amazing, but surprisingly hacky in some ways. The RPL language had a system of embeddable objects in memory, but when the interpreter had to skip over an object (i.e all the time), there was no field marking its length, so it had to actually recurse through all the sub-objects to find the end.
IIRC there was the a hack where some memory locations could contain a direct pointer or a pointer to a pointer, and it would work either way because the same bits could be interpreted as a pointer or directly executed... or something of that sort.
The French HP48 phenomenon was always interesting to me. How did that happen? I'm in the US and we had a French high school student visit over the summer. Always talking about the HP48SX, though he didn't bring it with him. But when I needed to get a graphing calculator I ended up buying an HP48GX instead of the recommended TI-83 (I ended up getting one of those as well). I used the 48GX throughout middle school and high school w/Meta kernel, Erable - the developers of which all French, ended up working for HP ACO. Used a 50G later on. It was always interesting to me how the development powerhouse for the HP48 series was all French, but never really understood how that happened. Was there some schooling mandate similar to TI in the US?
It was a hacking scene with a few talented guys with strong enough personalities to organize meetups and write fanzines articles.
Also, the model was popular in preparatory schools because of the expansion slots, it was possible to extend the memory by a huge margin.
This memory was useful to store, well everything you could, and at the time those calcs were not forbidden during exams.
Some people (including me) even wrote text editors and viewers with support to display a mix of text and picture for schematics, physics or chemical diagrams...
The US scene was also extremely helpful, with people such as JK Horn or Eric Rechlin.
Most schools recommended TI instead of HP (at least in the late 90s). The few people I knew who also had an HP48 or HP49 tended to be enthusiasts and all ended up studying CS at an Engineering school.
I have the strong feeling that hp28/hp48 have a deep impact in IT industry given the number of smart and passionated peoples who self taught themselves low level programming before 18yo with them.
Im 43 it guy and started playing with hp at 12, my own first « computer » with countless hours: playing, coding, debugging, reading txt files. Naturally when I bought my first intel computer at 19yo I installed freebsd, to later go to openbsd and Linux.
And the first thing I do on my android phone is to install hp48 emulator.
Most of the people who were active in the HP48 scene turned out to be good to great coders with a good knack for low-level optimization.
You may have heard of LZ4 or ZStd, the author is a French guy (currently employed by Facebook) who started hacking compressors on his HP48, this is how I met him a long time ago.
It had pretty good hardware I would say for the tradeoffs involved. One thing you should remember is that 30 years ago, the current semiconductor processes meant that if you put a faster/more capable CPU or color display tech in it, it would not last very long on batteries. The HP48 had phenomenal battery life on 4 AAA. A hand held gaming system like a game gear or Atari Lynx would last only a few hours on 6 AAs.
I think it was an Amazing Architecture. As far as I know Complex Instruction Set CPUs (CISC) was slow and then outperformed by RISC one but Saturn was very smart:
- The basic Calculator arithmetic is handled by the CPU, the CPU precision is the SAME of the calculator, and the digits can be printed on screen with little effort.
- The tiny hardware stack make the CPU quick: you needn't to make a major memory access to POP or PUSH return address the stack.
- The original tiny data bus (4 or 8 bit) reduced the production costs for low-end calculator.
- I/O and power saving was tight integrated: for instance there was a "deep sleep" mode to save battery.
Careful, you stop the clock if you put it to sleep. The clock is not great (large deviations in clock quality), but I like to have all my clocks more or less within 5 min.
> The HP 49 series initially used the Saturn CPU as well, until the NEC fab could no longer manufacture the processor for technical reasons in 2003. Therefore, starting with the HP 49g+ model in 2003, the calculators switched to a Samsung S3C2410 processor with an ARM920T core (part of the ARMv4T architecture) which ran an emulator of the Saturn hardware in software.
Surprising, but also pragmatic, but then again is that really cheaper than porting a calculator os to a modern CPU?
> The HP 50g, the last calculator utilizing this emulator, was discontinued in 2015 when Samsung stopped producing the ARM processor on which it was based.
This family of calculators was built around RPN, a Forth inspired language.
The thing is that language tokens were not exactly interpreted in the classical way, they were converted to address of routines in the 512K ROM (or RAM for more dynamic objects)
Programming language, OS and hardware were very closely coupled.
> is that really cheaper than porting a calculator os to a modern CPU?
There was a whole OS and programming environment in there, very closely tied to the CPU architecture. All the calculator's advanced functionality, including graphing, equation editor UI, equation solver, compiler and decompiler, etc., was written in the OS's own stack-based system language. Porting all of that to another CPU family would definitely have been much more work than writing an emulator for the old Saturn CPU. Performance must not have been a problem, thanks to ARM and Moore's law.
Quite different, by try "porting" NES games to a modern CPU, for example using zero page instead of just doing operations between registers that more modern CPUs allow unlike the 6502. Different programs from different times were made with different assumptions. It's much easier to emulate (and they games will actually run correctly).
One of my big contributions to the HP48 community was aggregating a bunch of information into a single guide in the late 90s, as well as documenting a ton of hardware quirks:
I still have a 48 series graphic calculator with this processor. I won it as a prize in a programing marathon when I was in college. Too bad I alread had passed all my calculus and phisics classes.
I got a 28 in college which was the predecessor to the 48 and also had the Saturn. The 48 was out when I got the 28, but I liked it how the 28 had a clamshell case, but the 28 would inevitably self-destruct by pushing the batteries out the battery door.
I replaced it with a 48g and later got a 50g (which my son uses) and more recently got an HP Prime which is unrelated to the 48 line, but is an absolutely excellent calculator
I loved my HP calculators (48g and 50g) in college. HP Forth/RPN is so much more intuitive at every step.
When you're entering the problem, you solve it the same way you would on a sheet of paper. I always felt this made me understand and appreciate the formulas more. It is also MUCH faster to calculate. Anecdotally, the couple RPN users could generally have the answer while the TI users were still checking their parens. I'd also note that doing the problems step-by-step gives a better intuition for when something seems off as you see the running answer at each stage rather than just the output. I'd also note here that advanced HP calcs included a formula writer that looked WAY better than any TI calculator pre-Nspire if you really do want to use do that (along with a CAS system to operate on those formulas).
HP Forth is where the game really stepped up though. TI-BASIC not only takes quite a few lines to do anything. Worse, you only interact through prompts instead of function call-style syntax. Meanwhile, an RPN program you write looks and behaves exactly like a built-in function and is written the same way you'd do it yourself.
An easy example I used rather frequently when in school is the inverse of inverses in circuits class. If you want to find the equivalent resistance of 4 resistors on a TI calculator, you'll type in `1/(1/2+1/3+1/4+1/5)`. On raw RPN, you'd type `2 inv 3 inv 4 inv 5 inv + + + inv`. There's a moderate savings of 4 keystrokes here (I didn't add all the `enter` needed for each number which is 4 in total) and a further savings that is harder to quantify because you are just mashing the `+` button a bunch of times.
The real savings is in a forth "macro". Create a program called `rinv` and have it rely on two numbers being on the stack. Programming is as simple as `inv swap inv + inv` which is the exact same way you'd do it by hand (for 2 entries already on the stack). This will be available in the custom function bar at the top, so it's ergonomic to reach too. Suddenly, this tiny program has turned our previous problem into `2 3 4 5 rinv rinv rinv` and we have blown away the TI method in speed. Not only that, but because we see all our raw resistor values in a column, it is much easier to double-check them. It works for any number of resistors as well and because we're just mashing the same button a bunch of times, entry is also sped up (I remember writing a custom version that did 4 numbers at once, but the speedup was miniscule and not worth having to select between the two).
I can already hear someone talking about how TI-BASIC exists. There are a few major disadvantages though. Let's say you want to solve for just 2 entries (the easiest version for the TI). You create your `rinv` program and then write some lines to prompt for the resistor values, then some more lines to do your math on them, then another line to spit the result to the screen. This is its own separate mini-game that has nothing to do with how you'd normally use the calculator.
Using this is also a bad experience. You must find the function menu, scroll to your function, and run it. Then, you must interactively enter your inputs one at a time (made a mistake? too bad). Now it spits out an answer, but that answer is not going to your problem, but to a previous line. This is fine if you just want the resistor value, but not so fine if you want to immediately use that value in your current problem. I'd note that you can use inline function calls on the TI-89 which helps a lot.
It's about this time that you discover you sometimes need 2 inputs, but sometimes you need more than 2. The HP relies on the idea that you can recalculate using the previous resistor value, but reusing values here is not really a thing (who wants to copy/paste 10+ decimal places into the prompt?), so now you have to revisit your mini-game and add a loop and way to check for a non-numeric value. You will also find out that the TI-89 arguments are not optional and must be a fixed number, so solving this puts you right back in unergonomic land again.
In the end, the TI has written lines and lines of code instead of just 4 characters and despite this, it is still slower to use and more subject to entry errors that aren't as obvious.
Once again, you see the iterative learning of the HP vs the "jump to the answer" of the TI. Once I'd understand how a problem was working, I'd write "macros" to solve the repetitive bits allowing me to shift focus from the "how" to the "why". I'll readily admit that I don't use my calculators a whole lot these days, but my college self owes it quite a debt of gratitude.
When it comes to calculating, RPN seems like it be more direct and correct because it is actually what an expression actually means, a series of steps. Algebra tends to abstract that.
That said, as a once upon a time (and sometimes still) theorist, familiarity makes working with algebra just easier. You also tend to logically group terms together merely because that's how things are written, with multiplication implicit by writing factors together but having to write out the infix + (or -) out and it makes it easier, in some ways to reason about expression in physical[0] way. For example, you see people doing various expansions, like perturbation theory, and then assigning physical meaning to terms (like linear term is simple harmonic oscillator, quardratic is this non-linearity, and so on in the taylor series). This grouping of terms is totally due to the abstraction infix notation gives you.
That said, people get lost in the abstraction and forget it's just steps in a calculation. Forgetting the actual meaning of the notation is where mistakes and confusion about things like convergence and such really stem from (I can flesh out this argument but I'm already rambling here). It also is part of the reason I think that some scientists find programming hard to understand because they are so tied to the mental abstraction of infix notation, whereas infix is literally what happens on a computer anyway, and is thus naturally suited to a programmer's mindset.
So there's value to both, I think. It is a shame though that RPN isn't as widely taught or used as it once was.
[0] physical in the sense of physics interpretation.
HP48 was awesome, but now, quarter century later, I like HP42 (also Saturn-based) better. It’s more convenient for simple tasks, and I no longer need to do complicated ones on a calculator. It’s also way faster, and smaller - it’s exactly the size of my iPhone; HP48 is about 50% longer and much thicker.
I've tried Free42, but never really warmed to it. More comfortable on the 48/49/50.
That's pretty much delegated to an iOS app now, but mostly because of the backlight. The display is simply better. The keyboard not so much (being a touch screen), but win some, lose some.
I certainly like the programming model of the 48 series over the 42. RPL is a really delightful language and environment to work with on device.
I never did much off device work, but coded up a bunch of stuff back in the day on the calculator itself. REPL development doesn't get much purer than this. Along with a stepping facility, and trivial unit testing, it makes developing stuff a real treat.
I can honestly say there's nothing easier to work on when lying in bed.
I was watching one of Ben Eater's videos recently, and realised that the machine code he was demonstrating seemed very similar to the way an HP42s was programmed. Was programming the HP42s basically machine code?
Maybe Saturn is edible. I think the only significant component of the the mantle that isn't a gas at STP is water ice, though maybe it would have enough ammonia dissolved in it to be unappealing.
This is great! I have no idea why but I'd always imagined that moons were a maximum of about 1 planet width away, maybe two. I guess the reason this isn't that case is that any planets would have had to have been that close would fall into the surface of their parent planet.
> This is great! I have no idea why but I'd always imagined that moons were a maximum of about 1 planet width away, maybe two. I guess the reason this isn't that case is that any planets would have had to have been that close would fall into the surface of their parent planet.
What a weird comment to make about HP saturn line of CPUs.
I really loved learning how to push this little gem to its limits, so many tricks were possible with the weird addressing schemes.
(I wrote a hobby OS for the HP48 series when I was a student)
https://www.hpcalc.org/hp48/apps/shell/