Omnimaga
Calculator Community => HP Calculators => Topic started by: supergems on October 27, 2014, 04:14:24 am
-
Hello everyone, some games based on openfire (http://fly.srk.fer.hr/~manjo/openfire/) can be found here:
http://fly.srk.fer.hr/~manjo/openfire/games.html (http://fly.srk.fer.hr/~manjo/openfire/games.html)
Best regards
-
Did you make all of these? This stuff looks pretty old. (not just the dates on the files, but also the "new" gif)
-
Wow, those looks amazing. I wish I had that calc. I wish that people still made games for those calculators since they are still sold by HP. :)
-
Yup, those look pretty sweet (and old :P)
-
The openfire banner on top wastes a lot of precious screen space though.
-
Yeah it reminds me of pure Basic graphical CSE games. It's most likely an Openfire limitation
-
There should just be a splash screen at the beginning of the application just like the free version of Game Maker on PC.
-
Yeah I agree. I don't understand why they did that D:. I mean I'm ok with promoting a language or engine (if I ever made an RPG Maker or something for calcs it would have an Omni logo somewhere) but as long as it's at the beginning of the game.
-
The banner is placed there because that space would be empty otherwise. The games are ports of 49G games, so they only use the 131*64 pixels of that calculator.
The 49G had different hardware, and even though the transition from its real Saturn to the ARM-based Saturn emulator of the 49G+/50G was mostly seamless, the development team took advantage of the emulator's additional possibilities and installed another screen with 16 more lines and other differences. Thus the old grayscale routines were one out of just a few things breaking between the 49G and 49G+.
OpenFire has some modes designed to facilitate porting old games by adding a few calls to its code. That code does some magic to emulate the old grayscale techniques. Newer games would use 80 rows and other modes which use hardware grayscale (2-bit with palette or 4-bit) of the new display instead of the old page-flipping tricks (multiple 1-bit buffers, can lead to flickering if the pointer to the active buffer is not switched between them fast enough) employed on the 49G and the even older 48S(X) and 48G(X).
Slightly offtopic:
DJ, you may remember Code Golf #5 (the Snake one). I had a OpenFire version in the works, but it wasn't finished in time. I might pick that up again if there's someone interested. It'll be compatible with the real calc only, though - Emu48 does only Saturn emulation (they can emulate most of the 49G+ and 50G through modified ROMs, but OpenFire is incompatible at least because it uses ARM code), and x49gp does not handle grayscale at all. (Luckily it's open source, so someone [TM] could patch that. (Additional info for this someone: the place to change is s3c2410_lcd.c:153-174) The next issue is OS compatibility: I haven't been able to compile it for Windows, but admittedly I didn't try very hard yet.)
Emu48 does run old 49G games, and there's even an easy way to get an instance of that running: the Debug4x SDK contains it along with the correct ROMs and KML scripts and everything. Don't tell anyone, though; of course the ROMs are copyrighted. ;)
-
Thanks for the good info. I have an HP 50g floating around somewhere. When I got it though there was virtually no info about it (or games) that I could find on the web. It's a shame because it's actually a pretty powerful calculator hardware wise. When it came out, I think it was actually the strongest. If there was more exposure and info on it I think it could have done much better.
-
Aaah I see now. I really need to figure out where to buy a 50g for cheap (until last summer they were almost $210 in Canada excluding taxes and now they're no longer sold here). Would the 49g+ be reliable or is it really as bad as some reviews claimed? Not that I plan to develop for the 50g since I prefer focusing my energy on HP PPL and 84+CSE hybrid BASIC, but I would still like to be able to try some programs one day.
-
The cheapest option would probably be Ebay. I got mine three years ago from there for about US$ 100 + shipping from USA to Germany. Still cheaper than the Ebay sellers around here, but I had to wait almost two months. Apparently it came by ship instead of by plane.
A quick search from over here resulted in this (http://www.ebay.com/itm/Hewlett-Packard-HP-50g-Graphing-Calculator-SD-Card-Slot-NEW-Scientific-Math-Etc-/251462657625?pt=Calculators&hash=item3a8c57a659) being the cheapest one by far. Given your different location, you might find a cheaper seller (because Ebay likes to filter out sellers not shipping to where people are querying from). Also, there is a 50G version with a different color scheme (blue instead of black) and a different pouch, but I prefer the black one.
The 49G+ is not as pretty, and it's missing one of the communication ports (which is rarely used nowadays though, because it has USB and an SD card slot). The reports about hardware quality are varying, but the newer ones supposedly are close to the 50G. Unfortunately, judging from this (http://www.hpmuseum.org/forum/thread-1717.html) thread on MoHPC (which also explains what to search for) the good ones are not easy to identify.
One more comment from a former Casio user who converted to HP: These calculators are operated in RPN, which takes some time to get used to. They do have an algebraic mode, but they are much more powerful in RPN. Since you have a Prime, I'd advise you to switch it to RPN (even though the Prime's RPN mode is quite crippled) as a training before you get a 49 or 50.
And finally I want to direct your attention towards this (http://hpgcc3.org/) site with two interesting 50G projects, one being HPGCC3, a utility to write programs for the ARM-based calculators in C, and the other one being newRPL, a firmware replacement project in the making - they want to get rid of the Saturn emulation layer by writing an OS running directly on the ARM processor with functions similar to the existing OS.
-
HP has done very little advertising to the HP 50g calculator and lately the price is lowered very much:
the calculator costs € 84.95/$ CAD 121,1993 at DYNATECH (send worldwide): http://dynatech.de/produkte/produkt.php?prod=4143 (http://dynatech.de/produkte/produkt.php?prod=4143)
http://www.shopbot.ca/m/?m=HP+50g+calculator (http://www.shopbot.ca/m/?m=HP+50g+calculator)
http://www.amazon.ca/Hp-HP50G-Calculator/dp/B000GTPRPS/ref=fallbacksessionReftagoffice_1?ie=UTF8&refRID=0PRHSBK8BEJ1GT0CW4GN (http://www.amazon.ca/Hp-HP50G-Calculator/dp/B000GTPRPS/ref=fallbacksessionReftagoffice_1?ie=UTF8&refRID=0PRHSBK8BEJ1GT0CW4GN)
some useful programs to manipulate images:
cgrobedit
http://www.hpcalc.org/details.php?id=7033 (http://www.hpcalc.org/details.php?id=7033)
PGM Viewer
http://www.hpcalc.org/details.php?id=7095 (http://www.hpcalc.org/details.php?id=7095)
Calculator Picture Editor
http://www.hpcalc.org/details.php?id=3837 (http://www.hpcalc.org/details.php?id=3837)
Open Fire Image Converter
http://www.hpcalc.org/details.php?id=6155 (http://www.hpcalc.org/details.php?id=6155)
PGM to GROB
http://www.hpcalc.org/details.php?id=3244 (http://www.hpcalc.org/details.php?id=3244)
XnView can read and write HP-48/49 GROB and read HP-49 OpenFire (gro2 gro4) -> http://www.xnview.com/en/xnviewmp/#formats (http://www.xnview.com/en/xnviewmp/#formats)
http://www.xnview.com/en/ (http://www.xnview.com/en/)
video player:
HPMovie
http://www.hpcalc.org/details.php?id=6290 (http://www.hpcalc.org/details.php?id=6290)
HPlayer
http://www.hpcalc.org/details.php?id=6278 (http://www.hpcalc.org/details.php?id=6278)
tools to develop programs in C:
HPGCC 2.0
http://sourceforge.net/projects/hpgcc/ (http://sourceforge.net/projects/hpgcc/)
Extend your 50g with C
http://sense.net/~egan/hpgcc/ (http://sense.net/~egan/hpgcc/)
HPObjects library for HPGCC
http://www.hpcalc.org/details.php?id=7177 (http://www.hpcalc.org/details.php?id=7177)
HPParser
http://www.hpcalc.org/details.php?id=7156 (http://www.hpcalc.org/details.php?id=7156)
HPStack
http://www.hpcalc.org/details.php?id=7157 (http://www.hpcalc.org/details.php?id=7157)
HPAPINE
http://kdntl.pagesperso-orange.fr/hp49/hpapine/ (http://kdntl.pagesperso-orange.fr/hp49/hpapine/)
HPGCC 3
http://hpgcc3.org/ (http://hpgcc3.org/)
x49gp
http://www.hpcalc.org/details.php?id=7161 (http://www.hpcalc.org/details.php?id=7161)
http://sourceforge.net/p/x49gp/code/HEAD/tree/ (http://sourceforge.net/p/x49gp/code/HEAD/tree/)
http://sense.net/~egan/hpgcc3/qsosx.html (http://sense.net/~egan/hpgcc3/qsosx.html)
some examples of videos made with hpgcc:
http://www.youtube.com/watch?v=7A2zKDHmoYA (http://www.youtube.com/watch?v=7A2zKDHmoYA)
http://www.youtube.com/watch?v=r4r2CY3xkjA (http://www.youtube.com/watch?v=r4r2CY3xkjA)
http://www.youtube.com/watch?v=bVQyBvD8bnI (http://www.youtube.com/watch?v=bVQyBvD8bnI)
-
They didn't do much HP Prime advertising either it seems, except online. They did more than the HP 50g but still not enough to grab a decent market share, not to mention the bugs (although I heard that back in 2006, the HP 49g+ had many bugs too).
Is the on-calc language available (I believe it's SysRPL, right?) viable for simple games or is it as slow as 68K BASIC?
And finally I want to direct your attention towards this (http://hpgcc3.org/) site with two interesting 50G projects, one being HPGCC3, a utility to write programs for the ARM-based calculators in C, and the other one being newRPL, a firmware replacement project in the making - they want to get rid of the Saturn emulation layer by writing an OS running directly on the ARM processor with functions similar to the existing OS.
Woah a new OS, if it gets released, unlike most Z80 calculator OSes other than KnightOS, would be amazing, especially if it gets rid of the emulation layer. With no emulation layer, even a language like TI-BASIC would rival TI-Nspire Lua in terms of speed and perhaps be much faster. Not to mention much faster graphing speeds. It's a shame that the 50g speed is not used to its full potential.
-
available language are UserRPL and SystemRPL, the latter is faster but more difficult... regarding newRPL from http://hpgcc3.org/projects/newrpl (http://hpgcc3.org/projects/newrpl) we read:
Introduction
This is the main page of the newRPL project.
The project aims to create a new RPL calculator environment to run in real calculator hardware.
Initially, the target will be the HP50g hardware, consisting on the following:
ARM 920T processor running at up to 200 MHz
512 KBytes of RAM
2 MBytes of NOR flash memory.
16-grays screen, 131x80 pixels
Areas of development
This project will develop the following concepts:
RPL execution environment: This module will be independent of the hardware, and provide the services needed to execute programs in the RPL language, such as compilation, memory management, garbage collection.
RPL language specifications: This module will define the keywords and syntax of the new language, numeric algorithms, data types, etc.
Hardware abstraction layer: This module will run on bare metal hardware and provide the basic services needed for the calculator to function. It will be kept to a minimum, to make porting to a different hardware easier.
-
That's good. If it's not too hard to learn for the average algebraic, HP PPL/TI-BASIC user, then I guess I might give it a go at one point. What if Reuben Quest series were ported to the HP 50g? :P
-
That would definitely be nice, but be prepared for a vastly different programming style. If you're still not discouraged enough, feel free to throw PMs filled with questions at me.
You could also try to set up an emulator first, HP isn't as aggressive as TI about those. Emu48 is the best one by far, and with Debug4x it could hardly be easier to get started. As I mentioned, it does not run ARM code, so some programs labelled as 49G+/50G-only will refuse to work, unfortunately including the OpenFire grayscale library. For those x49gp is a more suitable emulator, but it needs more processing power (two stacked processor emulators are a big CPU time sink), a Unix OS, for example Linux or OSX, and some experience with a Unix shell.
I have more good news: I decided to be that someone [TM] I mentioned a few posts earlier myself, which means my copy of x49gp now handles grayscale. 1-bit (i.e. the normal monochrome mode) and 4-bit (max depth) are tested, 2-bit should work as well. If I'm using this forum's attachment feature correctly, you should find two source code patches below, one fixing two compilation issues on at least my system and a minor error in flash.c I found a while ago, the other one implementing grayscale.
If anyone has problems using these, just ask, I'll see what I can do. x49gp is an old thing with not-too-good code based on an even older version of QEMU, so it would be pretty normal if something breaks. In fact, when I used x49gp the last time (on the Ubuntu version I replaced with Arch a year ago), one of the compilation fixes wasn't necessary yet.
-
I think I'll definetly have to dig up my HP50G again. If for nothing else, maybe to try some programs. How many shades of gray does it support, and is it good quality?
-
The 4-bit I mentioned evaluates to 2^4=16 shades, black and white included. Most 50Gs have a pretty clear display, so the quality is rather good. Unfortunately there are not many programs / games using this quality, even 2-bit (i.e. 4 shades) is not as common as I'd like. The only 4-bit grayscale programs installed on my 50G are OpenFire's image viewer and my 3D renderer test.
I have a quaternion-based 3D wireframe renderer lying around, and as an HPGCC3 program it was easy to allow the full 4-bit grayscale. But I like to develop on the go, which means cross-compiling on a PC (like with HPGCC3) is not an option. Another obstacle was the lack of grayscale-capable debugging environments till today (now x49gp can do that, it wasn't as hard to implement as I feared). That's why it's only doing my simple test case, a spinning cube. With a polygon-filling routine and some information about the game (because I only know it as "a simplistic 3D game"), Wolfenstein 3D or something similar is definitely possible.
-
Ah, that's pretty awesome. Most TI models only do 4 shades decently. The screen is too shitty otherwise for the most part. The old nspires support more, but they have native grayscale support.
-
This is hardware grayscale too. Also, I took another look at the pictures on the page linked in the first post. They are photos of a real 49G+ (I think the 50G didn't exist back then), so they pretty much show the quality on the 50G.
-
Ahh, ok. It's been a while so I didn't remember the Hp50G having a grayscale display.
-
Is the on-calc language available (I believe it's SysRPL, right?) viable for simple games or is it as slow as 68K BASIC?
Just adding my own experience in case anyone's curious. The built-in user-facing language is UserRPL, which I'd say is roughly on par with 68K BASIC speedwise, but often a lot faster, depending on what you're doing. SysRPL tends to work much more efficiently, especially for graphics. RPL in general tends to be “jerky”, though, because of the garbage collection method, which is a problem for games. Forcing a garbage collection each loop or few loops makes it smoother but a little slower.
As mentioned, RPL is a stack-based programming language, so the coding style takes a lot of getting used to (SysRPL, even more so), and especially debugging (though it includes an on-calc step debugger which is really helpful). Really long programs can be extremely hard to follow, but it's well suited for making lots of very small, manageable subprograms, which effectively form new “commands” in the language which you can then use to make higher-level subprograms, which can be used as commands, and so on, until you eventually create an entire large program or game out of them. (The HPs have nested directories, so having lots of separate subprograms isn't really a problem like on the TIs—and it's easy to organize custom commands/programs so they can be used in multiple projects, too.)
SysRPL is sort of a superset of UserRPL, has a number of more powerful commands, and allows you to bypass the error checking that usually happens in UserRPL. This can cause a dramatic speedup if you use it for loops that would call a lot of UserRPL words where you know that the argument types and such are correct and don't need to have every single operation recheck the arguments every time. Unlike UserRPL, though, you'll corrupt memory or crash the calculator if you mess up. It's quite easy to combine User and SysRPL code in the same project (they're both the same language internally); when I first started learning SysRPL, I just used it for the speed-critical parts and used the easier UserRPL for the rest.
There's also “HP Basic” which is UserRPL forced into a syntax of a more “normal” programming language. It's not that well documented, and I haven't messed with it much. It strikes me as being a bit of a kludge and lacking in places, and I hear it can be much slower than UserRPL.
The HP-BASIC/UserRPL compiler is of course built in as part of the OS, and there's a hidden SysRPL/ASM compiler and some hacking commands built-in, too, though you need to install a library to be able to use names for the internal commands (instead of hexadecimal addresses). A large amount of the ROM contains SysRPL code (with Saturn ASM for the low-level parts), and there are programs like Nosy that allow you to browse disassembled code right on the calc.
It can be a lot of fun for those who don't mind the “weird” programming language. The range of on-calc dev-supporting tools is just amazing.
-
The 4-bit I mentioned evaluates to 2^4=16 shades, black and white included. Most 50Gs have a pretty clear display, so the quality is rather good. Unfortunately there are not many programs / games using this quality, even 2-bit (i.e. 4 shades) is not as common as I'd like. The only 4-bit grayscale programs installed on my 50G are OpenFire's image viewer and my 3D renderer test.
I have a quaternion-based 3D wireframe renderer lying around, and as an HPGCC3 program it was easy to allow the full 4-bit grayscale. But I like to develop on the go, which means cross-compiling on a PC (like with HPGCC3) is not an option. Another obstacle was the lack of grayscale-capable debugging environments till today (now x49gp can do that, it wasn't as hard to implement as I feared). That's why it's only doing my simple test case, a spinning cube. With a polygon-filling routine and some information about the game (because I only know it as "a simplistic 3D game"), Wolfenstein 3D or something similar is definitely possible.
If you work some more on this 3D program you should showcase it here in case anybody would like to see it in action or try it :)