Isn't the calc supposed to have the same BASIC language as the HP 39gII? If that's the case, then it will be very fast (except maybe for standard sprites, if they're still drawn pixel by pixel).

The question, though, is: Will the calc and linking softwares be as buggy as the HP 39gII?

Do HP's communication protocols change often ?
Is there any third-party linking software for the 39gII and several earlier models (49g+ and beyond, I guess) ?

As far as third-party linking software, the HP-48/49/50 and 38/39 (not including 39gII)/40 line use Kermit and (for later models (later-production 48G*, 49, 50) or with third-party software) Xmodem. I'm not sure what the 38/39/40 line does exactly, but apparently it does use Kermit and Xmodem just like the 48/49/50 line.

So, you can use just about any modem-based terminal emulation/file transfer suite written ever for any platform. It's just that the HP software is optimized for working with a calculator. You can count the Kermit vs. Xmodem thing as a protocol change, but Kermit was still supported all along, so I don't consider it a major protocol change.

And, the 48SX was the first HP calculator to have a built-in method of linking to a PC for data transfer. The 41C line had a way of doing it, using the HP-IL interface, the Extended I/O Module, and an HP-IL ISA card for the PC, but that was clunky, and again, not built into the machine. (I believe most people who needed to do that a lot ended up using an HP-IL floppy drive as well, and sharing it between the machines.)

So, the 39gII was the first major change in link protocols in the history of HP calculators with on-board PC link support, to the best of my knowledge.

Thanks

So just out of curiosity, how does one draw except pixel by pixel on a screen that has pixels? I suppose a HW accelerator could possibly count there, but even when you get right down to it that is just pixels too.

Starting with your pointer to your bitmap object, and a pointer to your window object, the exact internal process goes something like this:

1. Check the size of your source bitmap and the destination location to determine if any clipping will happen.
2. If so, adjust the width/starting/ending values or exit as needed.
3. Write the line to the destination memory buffer.
4. Advance by the pitch.
5 Repeat until done.


The 39gII screen had an unfortunate characteristic that 3 pixels worth of data was packaged into 3 bytes or something funky like that. I've never seen an internal layout like that, and hope I never do again. This meant you'd end up with non-word aligned data and had to do shifting as you moved around to write the buffer. So it was definitely slower then being able to just directly write because of that.

For the screen on Prime however, the internal memory structure of pixel data maps directly to a format the lcd controller understands, so nothing special is needed there.

The big issue with drawing slowness in the programs I've seen for the 39gII though is that people seem to be trying to do the "copy the whole screen into a variable, blit in something, replace the screen from the variable and repeat" type of action. Of course creating new 10K variables each time is going to slow things down...

Well, I think he was more talking about how the BASIC-like language interpreter would draw the sprite -- either drawing all of the sprite and then updating the screen, or drawing one pixel, updating the screen, drawing another one, updating the screen again, rinse and repeat.

It's very gratifying and exciting to see the HP Prime now added to the array of delightful calculators in the Tools section.

Casio Prizm
HP Prime
TI 83 Plus
TI 83 Plus Silver Edition
TI 84 Plus
TI 84 Plus C Silver Edition
TI 84 Plus Silver Edition
TI 89

Thanks KermMartian

It seems like the 50g, at least, needs some type of strange, nonstandard cable, unfortunately, or so I've heard… though the protocol itself uses industry standards.

That reminds me—will the Prime have a built-in SD card reader? That's one of the greatest things about the 50g. I've never actually had to mess around with linking to the computer, since I simply transfer files back and forth using the SD card. Another industry standard thing, not to mention more space than I'd ever need to dynamically store and retrieve data and backups.

I'm more interested in assembly language programming, it would be great to be able to run assembly code on it. I don't much care for on-calc programming, but that is one thing that really impressed me about the 50g. Of the other calculators that have come out recently, this is easily the one i'm most excited about. The only thing i'm a little unsure about is the direction pad, not so much for its placement but rather for its shape. I've found the other calculators with a circular (Prizm) or rectangular (NSpire) d-pad to be more difficult to use, especially when trying to move diagonally. Everything else looks beautiful and i think the placement of the keys is actually quite nice. Can't wait to get my hands on one of these

All of the HP calcs use a non-standard port for serial. The 48S*/48G* use a 4-pin RS-232 connection, the 38G and 39G/40G/49G use a 10-pin RS-232 connection (I believe done that way to allow easier linking between calculators?), and the 39gs/40gs/late production 48gII/50g use a 6-pin TTL-level serial connection. (Note that the 39g+, early 48gII, and 49g+ don't have a serial port.)

However, the 39g+, 39gs, 40gs, 48gII, 49g+, and 50g all have USB. It's not a serial port (it's listed as a vendor specific profile), so someone would have to figure out what HP's doing to get a link program going. But, on the 49g+ and 50g, linking is unnecessary except for grabbing screenshots, given that the SD slot is there.



I haven't seen one in the pics/video... It'd be a shame if they dropped it for sure.



Of course, the 50g was a beast as far as on-calc programming went - on-calc Saturn *AND* ARM assembly.

Missed seeing this earlier...

Nah, what the nspire can do here is not even close. It can do a few simple things (conics come to mind), but how about these?

gcd(x,y)=1
x mod y=3
x^2+xy+y^2=4
cos(y/x)=x
x^3=5+x^y^2

(SIN((π/LN(2))*LN(√(X^2+Y^2)*(3*COS(((ATAN(X/Y)+(π/12))MOD(π/4))-(π/)+√(9*COS(((ATAN(X/Y)+(π/12))MOD(π/4))-(π/)^2-)))*SIN((π/LN(2))*LN(√(X^2+Y^2)*(3*COS(((ATAN(X/Y)+(π/12))MOD(π/4))-(π/)-√(9*COS(((ATAN(X/Y)+(π/12))MOD(π/4))-(π/)^2-))))<0

Also, try doing something like y=sin(e^x) on the nspire or casio (or any older HP)... it comes out rather poorly. Instead of seeing a nicely compressing waveform as you move in the x->positive directions, you just get some jaggies, or even repeating patterns in some cases.

I think when the promised screenshots are posted of some of the stuff that is capable, you will all be quite amazed.

http://nctm.confex.com/nctm/2013AM/webprogram/Session21265.html

Yup, that was where they first showed it off.

I have received three screenshots from HP, very attractive ones at that, but I asked them to please clarify the equations used to create each graph before I post them up. I figured you guys would want to see how the graphs match the math.

I mainly posted that link because screenshots are in there.

I did notice that they've got a formatting issue with exponents (not as bad as the one in the video, though ) - there's at least as much spacing there as a newline, when the 39gII has the exponent's baseline either 1 or 2 pixels above the base's cap height depending on font, and the 50g has the exponent's baseline (on default font) 1 pixel below the base's cap height.

If this, being a colored screen calculator, is as fast as I am hoping and reading.. Since both the color and touch might slow it down. Then I am really considering spending maybe $150 for it. I can't wait for user reviews.

It's got a 400 MHz ARM9 (apparently actually running at 400 MHz, too).

Compare to 132 MHz for the Nspire CX (which also has a 320x240 color display, although not touch).

Yeah, I think it'll be plenty fast.

I wonder if 400 MHz would be fast enough for Calc84maniac to port his TI-83+ BASIC raycaster to HP-Prime BASIC...

Color, yes, since you have more bytes per pixel to push, but I can't imagine that touch will slow it down terribly much. Touch events are hopefully handled in some sort of asynchronous fashion, which means they don't interfere with normal computation routines. And if HP has any sort of intelligent hardware designers, they have some sort of graphics co-processor or GPU to offload 2D drawing onto (something we continue to bemoan that the TI-84+CSE lacks).

I'm actually going to retract my guess that it's anything Samsung - nothing they have seems to be OTG, the S3C2416 and S3C2450 (the newest ARM9-based ones) are 1.1 host, 2.0 device.

I'm changing my guess to the Atmel AT91SAM9G15, although they're not using the resistive touch controller there if they've got a multitouch LCD. And, HP's already using an Atmel ARM7 part in a lot of their non-graphers - 2008+ 12C, 15C LE, 20b, and 30b.

The problem with CPU speed and touch, FWIW, isn't that it slows things down, but rather that it requires a faster machine to have an acceptable level of responsiveness for dragging things (rather than moving a cursor with a D-pad).

I really hope this moves the College Board toward relaxing their standards. It's those rigid standards that have handed TI their U.S. monopoly and allowed them to sell essentially the same hardware for over a decade at the same stupid-inflated price.