This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - 3298
1
« on: July 23, 2015, 09:48:09 am »
Thanks, it's always nice when someone says "welcome back". And it's kinda hilarious when a member with >5000 posts says "hey, I recognize you" to a member with <50 posts.  I also wrote and submitted Java and C entries with 127 and 122 bytes. For general-purpose languages that's a more reasonable size. SysRPL is extremely compact, probably because when HP's programmers wrote the 48/49/50 operating system, they were notoriously short on memory. ("Life is short and ROM is full." - William C Wickes) The system is implemented in a mix of SysRPL and plain ASM, so when the ASM code was as compact as possible, they squeezed every nibble they could out of the SysRPL parts. Thus there are tons of little code snippets called from all over the ROM (to reduce code duplication), and they are usable for user-written SysRPL programs as well, reducing my program sizes. On some occasions I've even seen code in the ROM which is decompressed on the fly, but mostly for parts rarely used during normal operation.
2
« on: July 22, 2015, 09:37:32 am »
Oh, Code Golf is back. I rarely visited Omnimaga for a while now because my standard browser doesn't like the available HTTPS encryption modes (time for an upgrade...), but if you look at the entries in JWinslow's original series, you may see a few entries written by me.
I just submitted a SysRPL program for this one, measuring 53 bytes - SysRPL tends to be pretty small. Unfortunately it's quite slow, more than 2 minutes for the entire output (may depend on available memory due to the way the garbage collection works; right now I have a lot of memory available on my calculator). It simply dumps the 8000 numbers to the stack, one by one, and leaves them there so the user can examine them.
I may also participate with Java, XTend and Haskell like last year, we'll see. Maybe even with C.
3
« on: October 28, 2014, 05:01:58 pm »
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.
4
« on: October 28, 2014, 04:32:56 pm »
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.
5
« on: October 28, 2014, 11:58:06 am »
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.
6
« on: October 28, 2014, 05:14:58 am »
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 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 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 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.
7
« on: October 27, 2014, 06:56:25 pm »
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. 
8
« on: October 08, 2014, 05:03:07 am »
So I spent some time with SysRPL and the subtraction/division version. The good news is that it's working. The even better news is that it's shorter than the submitted version by 1 command (i.e. 2.5 bytes). The bad news is that it's still slow as hell: calculating "97*3*2+7*" takes 4720 seconds. Though in theory it would tackle everything up to 2^20-1=1048575, which is slightly more than what's needed. I'll submit it as soon as the Java and C versions are corrected as well.
Edit: Java done, size reduced by 3 bytes. C mostly done as well, though I have problems with creating a large array as a local variable (i.e. on the stack), which was the real cause of the segfault. so malloc it is ... as a result, the size increases by 12 bytes instead of decreasing.
Edit #2: About 100 minutes for Java and 21 for C at 987654 on my laptop, that's ... still slow, but acceptable for a single test case. But by using strtol I was able to reduce the size of the C version to 7 below the my first one. So all three programs are now smaller.
9
« on: October 07, 2014, 02:12:26 pm »
Okay, I just found some code on StackOverflow by someone with your name, so I'm going to assume that's you. I'm also guessing that your current approach is pretty much the same as in those programs (without the fancy acceleration for huge numbers). My approach is similar, but I'm trying all combinations of numbers j, i < n where j>=i (cuts the time spent in half, this is possible due to commutativity), and then I generate j+i and j*i. As it seems, this generates way too many numbers beyond n (which I usually discard, unless this integer overflow bites me). It would have been nice if there was an O(n log n) algorithm, but the O(n^2) one will have to do. I'll subtract and divide instead of adding and multiplying then, I guess. That will at least avoid that integer overflow at 987654^2.
10
« on: October 07, 2014, 01:24:35 pm »
Well, the last four are beyond what JWinslow23 specified as the required range (0-999999). In theory my programs should get these results eventually (unless there's a bug I didn't find yet), but in reality my quadratic algorithm is apparently insufficient. The 50G is still crunching 1337 (at least 20 minutes have passed ... I won't test the others without a turbo-mode emulator!), the Java version did the 12345 within a minute and got an integer overflow after chewing the 987654 for 15 minutes or so, resulting in an ArrayIndexOutOfBoundsException. I got a segfault from the C version at 987654 (though immediately) after it did 12345 in what felt like 20 seconds. I'll see what I can do to fix them up.
Is there an algorithm with better complexity than O(n^2)?
11
« on: October 04, 2014, 03:28:39 pm »
Okay then, my SysRPL, Java and C entries are done. My fourth question was actually meant in a different way ("thirty-one" is 10 chars, but all the examples look like we shall count the 9 letters only), but your answer reminded me that the dash can be replaced by a space, simplifying my programs a little. Thanks for that. By the way: "forty" or "fourty"? I hope the latter is acceptable (despite my spell-checker complaining about it ... English is not my first language) because the former would break my concept of reusing the same lookup table for 13-19 and 2x-9x, and "forteen" looks just wrong.
12
« on: October 04, 2014, 06:56:41 am »
My output currently looks like this (for input 703450):seven hundred three thousand four hundred fifty is 41
fourty-one is 9
nine is 4
four is magicThe aspects I'm not sure about are these:
- Do I need a period at the end? (2-6 additional bytes, depending on language, so not too bad)
- Is the correct number written out in letters, or should I mangle the other one instead, or both?
- Do I need an upper-case letter at the start of each line? (That would be a pain to do!)
- The spaces and dashes should not be counted, right?
13
« on: August 29, 2014, 01:00:15 pm »
Is it OK if I'm getting 2, 36, 38 and 49 on the example string from the first post instead of 2, 4, 38 and 49? Both 4 and 36 are indices of o's between the c and d. If yes, I have a valid 96.5-byte SysRPL solution (74 bytes if case-sensitive).
SysRPL has no case-insensitive string search stuff except for some commands dealing with the edit-line. So I need to search for the uppercase and lowercase character and take the one that's closer to the string end I started at. Due to how "not found" is reported (0 is returned in place of the 1-based index), it's easier to start from the end instead of the begin (max of the two numbers vs. if one of the two is zero, then max else min).
I also have a shorter Java program (189 bytes) and XTend and Haskell programs (163 and 174 bytes).
14
« on: August 18, 2014, 08:07:41 pm »
Which calculator is your SysRPL entry compatible with by the way? I write it on my 50G of course, and due to the negligible differences between 49G+ and 50G (the 50G is mostly a hardware quality upgrade, and returned an IO port the 49G+ was missing ... I believe it was the serial one) it should always run on the 49G+ as well. I usually try to make my code compatible with the 49G (real Saturn processor instead of an emulation with extended instruction set on top of ARM9, and a display height of only 64 pixels instead of 80), but this one draws a line in the 65th row (i.e. just outside the display area) which could possibly corrupt the memory. I also had trouble turning off the softmenu (bottom 8 pixel rows or so), and in the spirit of Code Golf, I didn't bother with it because it was not in the way on my 80-line display. While not in my focus, the 48GII (Saturn emulation on top of ARM9, but 64-line display, and some advanced math features are removed) might run my programs as well. I'm pretty sure I'm not using any of the missing features in this one, but again, the line in the 65th row might be a problem on the small screen. Generally all 49G-compatible programs not using the removed features should be fine. But don't ask me what features these are exactly, I only read that the 48GII is feature-wise betweenthe 49G and its ancestor, the 48GX. Compatibility with the 48S, 48SX, 48G and 48GX is highly unlikely. I think none of my Code Golf submissions are compatible at least due to use of the ZINT data type and Flash Pointers, which were not present in those. Was that enough of compatibility talk?  Those 49G(+)/50G calcs gotta be the only calcs with on-board ASM development tools. Okay, I heard about two weird old Casio models with C as their primary language, and a third-party language on some TI calcs compiled to native code (that was called Axe, right?). At least these tools are pretty handy for development on the go. And as usual, most of the documentation you need is available in calculator-compatible formats as well. There are some libraries shipping with only HTML docs, but meh, that on-calc web browser has an offline mode, too.  It's skipping the images, but the formatted text is all I need. About future Code Golf challenges: I wouldn't mind some more complicated problems. Say problems related to graph theory or cryptograhy. A full game may be a bit overkill, but the other ones were pretty trivial.
15
« on: August 18, 2014, 03:06:46 pm »
Wow, I got the shortest entry this time.  Apparently this nut was too tough for Golfscript and CJam. Though I have to admit that the concerns I expressed above still apply to the version I submitted (it is in fact the same version I had when I wrote my previous post). I was working on a grayscale version, but that one is still not finished - and likely will never be because this round is over. Probably it would have ended up bigger because it needs to contain the grayscale system - there is not much existing system code I could recycle for that.
|
Show Posts