Hi,
I just tried the free GNU Emu48CE for Windows mobile 2002/2003.
It comes along with all you need (ROM image, Skin bitmap file, *.kml file) for emulate a HP38G, HP39G, HP40G, HP48G and HP49G.
But I used a HP48SX for a very long time and that's a bit different to HP48G. So if there are any Skins and *.kml files fitting on a 320*240 PDA it would help me a lot, because I wrote many small apps for it and these will not all run on a HP48G.
JH
the kml is just the gui layout
of device
the difference between 48S and 48G is purely a rom thing
here you can find kml and prob roms too for the emulators
http://www.hpcalc.org/hp48/pc/emulators/
if you dont like to do the messing on the pda you can do all the work on the pc version and then just change the rom on the pda when you are ready
odd that they would not work on 48G
that never been an issue for me
Hmmm...
I don't know much about the emu and his configurations. Maybe the klm works as it is also with an SX GUI as long as the keyboard layout is equal. But even if it is only the matter of the ROM and not of the klm to interpret a keypress right, the lettering of the keys (bitmap) does not fit to a HP48. Same keys have not the same function on both calculators. It's a little bit like trying to type english on a keybord with greek letters on it...
OK, I can change the gui on my own, but I'm quite sure that someone else already has done this before and I try to avoid spending time on doing things other have already done and perhaps much better than I can do...
I will see what I can find at http://www.hpcalc.org/hp48/pc/emulators/ ...
it's quite much to read...
I think the most apps from my 48SX will work on an 48G but some of them uses direct system calls (SysRPL) and some entry point may have changed...
JH
Related
im trying to compare these two dll files but i dont reall know how to
I use this app.
http://www.ultraedit.com/index.php?name=Content&pid=34
I also recommend the free (!) WinDiff, on which I've elaborated in depth at http://discussion.brighthand.com/showthread.php?t=215073
hmm i like the ultraedit but it makes the dlls look all wierd. maybe its supposed to be like that.
my problem is that the dll bta2dp.dll from tornado makes the a2dp work. and the bta2dp.dll from treo 750v does allow it to work.
i feel this file is necessary but i dont know the differances
I presume that's a typo because as I read it, both dll's allow your application to work?
I don't understand the problem, if you have have one that works then isn't that the solution? I don't get what you're trying to achieve. DLL's are composed of functions which are dynamically linked to at runtime from the application code. If the parameters passed from the application to the function in the DLL differ from one version to another, or the return information is different then that's the reason why one works and the other doesn't.
Unless you have the programming skill to debug the procedure as it is entered and subsequently change it then there's nothing that you're going to be able to do other than compare version numbers of the files but since you have already found one that works, what's the issue?
David.
(Now I've noticed you try to compare binary files - windiff is only usable for comparing textual ones. Sorry.)
Hi all you great minds out there.
I've been hunting around for a little while trying to find out if this is possible.
I've got this program on my PC called Guitar Pro, a cracking little program which plays midi and guitar tabs together on screen so that you can follow on the guitar, theres a huge online archive of songs that have been converted to guitar pro *.gp3/.gp4/.gp5 format.
Its been great but I find it most annoying that I have to sit in front of my PC to work with this program, so I was really hoping for a program that would recognise the Guitar Pro tab format and run them back a full/half speed ect. I not even that fussed about the midi background.
Now, according to the Guitar Pro website, they MAY release a pocket PC version, this has been the stance for about 2 years, so I can imagine that its a non starter.
Looking around the net I found a program called DGuitar which is supposed to be able to run on any platform with Java, I managed to get a .Jar file to play with but it doesn't install on my pocket PC (would have been a bit too easy eh)
I dont suppose anyone has any input to this conundrum?, perhaps Im being a bit of a lemon with the DGuitar JAR install? or maybe theres another bit of software out there?
Id love to hear everyones input into this, cheers in advance y'all
P.S. I attach the open source DGuitar files to this mail perhaps someone might be able to take a better look at the distribution files
I'd love to be able to use Guitar Pro on my PPC. I'm unable to download this DGuitar file at the moment so I can't verify whether I can get it to work, but I will definitely be watching this thread.
please do, Im tempted to put a flash app together, since my Java skills are lacking. The Flash Lite platform is pretty good.
u should try this..
i think dguitar technically will work on your device together with java emulator software..
Unfortunatelly it's not so easy to convert Java SE (Swing) application to a J2MEE one. There are a lot of problems and as here we would need to convert both GUI and MIDI (sound) I think it's better to find an application predestined for PPC.
Maybe you could use Milktracker. Not exactly guitar but piano! http://www.milkytracker.net/
Or maybe :
MilkyPlay 0.9.7
MilkyPlay is a free module player for PocketPC supporting various formats.
Features:
- support for 669, AMS, AMF, CBA, DIGI, DSM, FAR, GDM, IMF, MOD,
MDL, MTM, MXM, OKT, PLM, PSM, PTM, S3M, STM, ULT, UNI and XM
- linear interpolation for better sample quality
- volume ramping for click removal
- audio visualisation
- nice GUI
- Song info viewer (instruments/samples/songmessage)
- playlists
- shuffle playback
- configurable button layout
- support for zip compressed modules)
http://peter.nxbone.net/MilkyPlay.zip
Not tried links recently.
Or maybe this link:
http://freewareppc.com/multimedia/pianonm.shtml
Or this other commercial one:
http://www.pocketpccity.com/software/pocketpc/Guitar-Fretboard-Addict-2005-12-16-ce-pocketpc.html
Sorry if I am barking up the wrong tree!
After recently coming across the open-source DGuitar project, I became interested in seeing if it was possible to port it to run on a win mobile JVM. As mjanek20 said earlier, the two major obstacles in doing this would be getting the Swing GUI components and the MIDI playback to work on these limited devices. The GUI components are actually not that big of an issue. On most WM devices, third-party JVM's (such as Creme) are available that support AWT and/or Swing components. The *really* difficult part is going to be the MIDI support. I've done a lot of research on this in the last few days, and I can't find any support (Java or otherwise) for low-level MIDI progamming. At best, there is support for playing back an entire MIDI file, but this is not appropriate for a Guitar-Pro viewer/player, where individual MIDI events need to be sent to the MIDI device in real-time. As I see it, there are three possibilties:
1) Substitute the MIDI events with simple tone events. This will give us basic sound, but we will be missing all the nifty effects like sliding, bending, hammer-on/off, fret noise, palm muting, etc.
2) Use a MIDI file exported from a GP file, and try to play this back in sync while displaying the tab in the GUI. Not sure how viable this is, just an idea at this point. I would hope it would solve some of the problems noted in solution 1, but syncronization and looping sections might be a problem here.
3) Program my own MIDI-to-PCM engine. I think some people have already done somethng like this (for instance, I am guessing the guys that came up with the Vibe MIDI sequencer midlet rolled their own), but unfortunately I havent found any open source, and frankly I'm too dumb and lazy to build something like this from scratch...so I'll probably start with solution 1 and then maybe see about implememnting solution 2.
I'll post my progress with the DGuitar port when I make a significant breakthru....if anybody else has any good ideas about a MIDI solution, let me know.
what is your progress with this? have you stop?
Hi,
So what is the actual progress?
I don`t really need the Midi playback, it would be perfect to just view the Tabs of a GP3, GP4 or GP5 File!!
Any other app around?
Regs
Sideburnt said:
Looking around the net I found a program called DGuitar which is supposed to be able to run on any platform with Java, I managed to get a .Jar file to play with but it doesn't install on my pocket PC (would have been a bit too easy eh)
Click to expand...
Click to collapse
DQuitar was written in Java indeed. But not in JavaME (ME stands for mobile edition) which is supported by most mobile phone. This is a huge different, and unfortunately DQuitar will not work on mobile devices.
Maybe it could be worth trying using JavaFX from Sun/Oracle while it's still available for our PPCs.
Jbed can run almost nothing where JavaFX behave correctly (except for on-the fly screen rotation). For instance, display is completely messed up using Jbed with Angry Birds, while the game is completely functional using JavaFX.
Quitar
I've been posting left and right on these forums since I got my new phone (Blackstone). I've done some programming before (c/++ and java) but mainly more scripting in Matlab and maple (if you can call the latter scripting ).
But since I've gotten my new HD, I've been wanting to program for it. So I thought my first program would be a simple but fun multiplayer game, which would allow me to learn c# in the process.
I've gotten hold of VS2008 through my uni, and a few different C# books (couldn't find a specific WM6 C# book though, and MSDN is a huge mess, what with obsolete libraries, mixing WinEmbedded and WinCE with compact.NET and a mess of unusefull and incomplete pseudocode).
So I've started through the books and it all seems kinda straight forward: classes are declared with their variables, the accessors/methods and constructors; you create an instance of the class and load in it's variables, then you draw them.
And now I'm stuck trying to just displaying a goddamned jpg.
I've attached my program code (VS2008 project) and the jpgs. What I'm trying to do here (before even getting started on the game logic) is just display a form with a background image, draw three menu buttons on top and a sound on/off button.
The start/options/exit buttons will lead to their respective forms, and the sound on/off button does just that.
What I've tried to do is create a new class. ImageBtn, which implements my button behaviour (show button, if pressed display pressedversion of the button and then perform action).
The Mash2 main() directs to MainmenuForm, which loads the bckgrnd and buttons using the mainmenufoprm.designer and the imagebtn class. The rest of the forms are placeholders.
Please, could someone who knows more of C# than me (ie practically anyone ) have a look at my Mash2.cs, FormMainmenu.cs and ImageBtn.cs to see what I'm doing wrong?
Am I not loading the jpg's correctly? Is my custom class not declared correctly? Is it a problem with my use of winArray? Or how I invoke graphics.drawimage?
I just have no idea, and what's more humiliating is that everything I look up on google gives me a different, badly written and obviously syntax incorrect example of how it should be done and they're all done using very different techniques.
PS: as I've said, I've attached my project files, but if people can't be bothered I could post the code inline. Also any links to WinMobile, compact.NET C# forums which could help would be much appreciated. Hell, any help would be a life^H^H sanity saver!
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S
bump
10 del al char har
bump
I tested it out and it works great! Thanks!
I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????
pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App
???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!
Hi.
Before I start with my question, just a little background. I work in a user guide development firm, and mainly work on Galaxy devices.
One of the most time-consuming process in my work is to match all UI strings (app names, menu text, labels, etc) of the actual device with the user guide.
This is currently being done with human power, with a staff looking at the user guide, check the device if this is correct, and annotate the draft PDF if the UI strings don't match.
If this was for just one language, it's doable. But with 40 or so languages (including Arabic, Cyrillic, Chinese), it definitely makes me want to puke.
This is a very tiring, eye-straining work that I'm trying to resolve, for everyone's sake.
I tried decompressing the Galaxy firmware myself, but the XML data is encoded into binary(for what reason I have no idea), and is not readable.
So now I'm turning to the masters and hope for any luck.
What I would like to know is ...
Hack the Galaxy firmware(md5), and extract UI strings for all language and save in spreadsheet or something, or
Mirror the device's screen on the desktop, copy the desired UI string, and paste it to a desktop application(e.g. Adobe Acrobat).
If the first option is possible, then I can utilize the data for some sort of automation, and would be the best.
If the second option is possible, then I would no longer have to type all kinds of foreign characters(this is also a very time-consuming work), and make some progress in timeline.
If all options are not possible, and there's absolutely no way of automating this process, then well... I guess I'll go see the eye doctor more often than now.
Any ideas or helps would be great.
Thank you.