Omnimaga
Calculator Community => HP Calculators => Topic started by: DJ Omnimaga on March 16, 2013, 01:14:54 am
-
EXPORT Test()
BEGIN
0->A
WHILE 1 DO
A+1->A;
TEXTOUT(A,1,1,2,0,65,2); // str/var,Y,X,FontSize,Color1,Width,BackgroundColor (0=black, 1=dark gray, 2=light gray, 3=white, transparent bg if not setup)
TEXTOUT(A,2,1,2,0);
TEXTOUT(A,3,1,2,3);
TEXTOUT(A,4,1,2,3);
END;
END;
Result: Bold text counter with a shadow behind. In 1 second, I can reach 150! This might look a bit slow, but I used 4 text commands per loop and 3 shades of gray (For some reason the speed seems to get faster sometimes, so much that I reached 400 once)
Also fun fact: The calculator language has rectangle commands, filled, not filled and inverted.
EXPORT Test()
BEGIN
0->A
WHILE 1 DO
A+1->A;
INVERT(); (no arguments inverts the entire screen by default. Light gray pixels becomes dark gray or vice-versa)
TEXTOUT(A,1,1,2,0,65,2);
TEXTOUT(A,2,1,2,0);
TEXTOUT(A,3,1,2,3);
TEXTOUT(A,4,1,2,3);
END;
END;
This time, I get 30 frames per second! However, it seems that the LCD is unable to keep up being updated in its entirety at such speed, so there's a lot of frame skipping and tearing (at least it doesn't appear to bottleneck program execution, though)
As a result of the slow LCD, I was unable to check how fast INVERT() alone in a loop was, since it just took like 4 seconds to update at such speed (with some static appearing at times as it inverted gradually)
Now for regular text:
EXPORT Test()
BEGIN
0->A
WHILE 1 DO
A+1->A;
TEXTOUT(A,1,1,2,0,65,2);
END;
END;
500 in 1 second. Frame skipping appears to occur, though. This tells me that if a game happens to run incredibly fast, it might need to be adapted so that it looks nice at lower framerate.
Now for the following code:
EXPORT TF()
BEGIN
FOR A FROM 0 TO 99999 DO
END;
END;
Executes in 4 seconds.
Have you taken note, TI? :P
-
Heh :)
-
Have you taken note, TI? :P
And Casio too ;D
-
Yeah too.
The only disappointment, though, is:
-Lots of bugs and crashes (had to pull all batteries a few times, although that didn't cause much data damage)
-Being forced to add ; after every line of code can get annoying at times, especially considering you need to press shift everytime
-You need to have the exact same firmware as the calc emu to send programs (and the latest firmwares for both aren't in sync), so basically I am unable to transfer files (although the connectivity kit lets me edit code, so I can copy it easily on the computer)
-There are barely any instructions about sending stuff, nor for the calc maintenance (for example, it isn't told anywhere how to use the flash memory).
-The lower the batteries, the slower the calc gets. This can be problematic for game programming, since nobody got the same battery level. It seems we can change this via the maintenance menu (ON+F4), but then it gets slower again and again so you have to constantly change it back to Full :X .
-The latest firmware I just got appears a bit slower in general.
The funny thing, though, is that despite running at 20 MHz, my Tunnel program actually runs faster than if an equivalent was done in TI-BASIC (in HP's case it is helped a lot by rectangle commands) or Casio BASIC.
This calc can be interesting for programming purposes and has some potential, but I would wait before buying it because it's not fully mature yet. IIRC it was released in China in 2012 before being released here and it's like if it was still in beta stages. If HP gets their act together maybe it could become great, otherwise it probably won't have a very bright future.
-
Interesting. I take it the 39gII is a recently released calc model? And it appears to support grayscale directly in the user programming language? That sounds pretty cool.
The HP 50g is rather weird—there is SysRPL (no UserRPL) support for manipulating grayscale graphics, but none for actually displaying them—they apparently leave that up to third-party libraries. Go figure. :P Actually, though, there was a grayscale Easter egg on some ROM versions, and I sometimes see gray pixels when I crash it with bad SysRPL code… I've never really explored grayscale on the 50g yet, so I don't know.
-
Yeah I think the screen supports 4 levels grayscale, and yes even the language lets you use it. It was released in 2012 if I remember, but only in China (probably the reason why they didn't do much effort fixing bugs and why the calc design looks like an old printer). Then in 2013 it was quietly released in Europe.
Also I just made this small program that fills the screen with squares (that has a white border and a different color):
EXPORT Tunnel()
BEGIN
0►X;
0►Y;
0►Z;
WHILE 1 DO
Y-ISKEYDOWN(9)+ISKEYDOWN(15)►Y;
X-ISKEYDOWN(14)+ISKEYDOWN(10)►X;
FOR A FROM 0 TO 4 DO
FOR B FROM 0 TO 8 DO
RECT_P(X+(32*B),Y+(32*A),X+32+(32*B),Y+32+(32*A),3,Z);
IF X>0 THEN
−31►X
ELSE
IF X<−31 THEN
0►X
END;
END;
IF Y>0 THEN
−31►Y
ELSE
IF Y<−31 THEN
0►Y
END;
END;
Z+1►Z;
IF Z>3 THEN
0►Z;
END;
END;
END;
END;
END;
This displays 45 flashing squares on the screen that you can move around. When they reach a certain location their position resets so it looks like a loop. In a bit more than a single second I can scroll an entire square in. If the LCD wasn't capped around 10 FPS I would get about 25-30.
I tried the same program earlier but with 16x16 squares instead of 32x32 (meaning 153 squares displayed per frame) and got around 4 FPS.
-
Very cool! ^^
-
This is not a color calc, correct?
Also, is the great speed a direct benefit of having the CPU built specifically for the calculator? I find that pretty cool about HP calcs. :)
-
Yup, it's a grayscale LCD (so not color, but not black and white either).
I had the chance to take a look at this calc yesterday, it kinda looks like the 68k line of TI calcs in terms of functionality (you can call programs as functions on the homescreen and stuff like that), but it's also pretty glitchy due to the LCD not being able to keep up with the processor.
-
Yup, it's a grayscale LCD (so not color, but not black and white either).
Interesting note is that HP calc screens have been capable of grayscale (not faked at all) for quite some time. ;)
-
Indeed, but this is the first ever model to let people use it inside BASIC programs without ASM libs.
-
Filling the entire screen pixel by pixel:
(http://img.ourl.ca//fillscreenbypixel.gif)
(http://img.ourl.ca//randomize.gif)
As you can notice, it's much faster than on the TI-84 Plus. However, it will not be fast enough for scrolling/animated tilemaps made of actual sprites. Single sprite movement (16x32 mario sprite, for instance) appears like it might be fast enough, though, because I get 20 frames per second on a 16x32 square. I get around 8 per second if I draw a 16x32 square made of random static (using the random function, which is a little slow) every frame.
On the other hand, a scrolling tilemap made of squares (all tiles are redrawn every frame) will be very fast:
(http://img.ourl.ca//squaretilemap.gif)
Of course both of those screenshots were artificially slowed down to match the real calculator speed.
Some notes:
-Games sent to the PC will no longer work on the calculator it seems. My tunnel game has to be recopied by hand in order to run, otherwise it will freeze.
-If you use the connectivity kit to edit your code, you need the emulator open in order to save it. This will then save the program in the emulator, allowing you to send it back to the calc afterward. Else, saving will do nothing.
-As you will see in the Tunnel topic, grayscale is absolutely terrible in the emulator. The LCD color is green-ish, but everything else is actually gray/black. This means that light gray is actually lighter than white! O.O If someone decided to render a Zelda game in it this is how it would look like:
(http://img.ourl.ca//howzeldawouldlooklikeinhpemu.png)
This is the latest emulator build: http://www.hp.com/sbso/product/calculators-emulators/graphic-calculator-emulators.html
-
Something off-topic, but I just noticed something: THe calc-to-calc cable that comes with the HP 39gII has a Mini USB A end, but the other is Mini B...
What's up with that? O.O (the calc only has a mini A port)
-
You mean with B end now the female end? O.O
-
Actually sorry I got it the other way around. The calc has the Mini USB B plug like the TI-84 Plus series, but one end of the link cable is Mini USB A male instead of Mini USB B.
-
with the A and B on the link cable for the 84+ that came, I never cared which one i plugged into which calc and it always worked....
-
THey both fit? O.O
-
I guess it has [wikipedia]USB_On-The-Go#OTG_mini_plugs[/wikipedia] like on TI calculators. The CX comes with a similar cable, and both ends fit.
-
Oh right now I tried in my 84+CSE and both actually fit. I guess it's the same for my 39gII then.