Planet maemo: category "feed:96cafbff7b5c987c48a8071d34a36135"
It's funny that, exactly one year after my previous post, my current pet project is exactly the same as it was last year! But both the hardware (N900 vs N950) and the software have been upgraded...
Despite the Twitter crazy, I still feel like talking a bit about some recent project of mine.
grmgpsd, an old school Garmin GPS protocol emulator. It was born by merging two of my older projects, nmeagend and garmintalkd. The first one was a NMEA "server" from the N900's liblocation data, while the second one was a Garmin binary PVT (Position - Velocity - Track) protocol server. Both allowed you do moving map on a PC using your N900 as GPS.
However, after implementing the PVT part of the protocol, I knew it would be extremely easy to implement the rest of the Garmin binary protocol. So I tried to find a use case for such implementation ;). The use case is as follows:
Yes, you can now use whatever software you used to manage your Garmin's GPS tracks, etc, to manage your N900's content. You can even use that software to exchange them! And, if the magic keywords are not uttered by the host PC, it will appear to be a off-the-shelf Bluetooth NMEA GPS.
What N900 content? Yes, good question. So far, it's all stored in sqlite database whose format was designed ad-hoc. I also made a very simple track logging application that fills the "Active track log" track in such database.
Yet, my plan is to use someone else's program as storage, like, for example, Columbus.
The source is, as per usual, available on my Gitorious.
grmgpsd, an old school Garmin GPS protocol emulator. It was born by merging two of my older projects, nmeagend and garmintalkd. The first one was a NMEA "server" from the N900's liblocation data, while the second one was a Garmin binary PVT (Position - Velocity - Track) protocol server. Both allowed you do moving map on a PC using your N900 as GPS.
However, after implementing the PVT part of the protocol, I knew it would be extremely easy to implement the rest of the Garmin binary protocol. So I tried to find a use case for such implementation ;). The use case is as follows:
Yes, you can now use whatever software you used to manage your Garmin's GPS tracks, etc, to manage your N900's content. You can even use that software to exchange them! And, if the magic keywords are not uttered by the host PC, it will appear to be a off-the-shelf Bluetooth NMEA GPS.
What N900 content? Yes, good question. So far, it's all stored in sqlite database whose format was designed ad-hoc. I also made a very simple track logging application that fills the "Active track log" track in such database.
Yet, my plan is to use someone else's program as storage, like, for example, Columbus.
The source is, as per usual, available on my Gitorious.
So the deadline is approaching, and slowly all features start appearing:
So the input context skeleton is finally in place, and gedit can start receiving commit signals from the MeegoTouch keyboard:
I can even create new documents and switch tabs while typing on it, and it correctly follows focus. Not much else to try yet!
Many thanks to murrayc for Multipress Input Method, from which I took many build system related bits and of course to Mohammad Anwari for the original Hildon Input Method.
Want to know what all this fuss about Maemo is about?
http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend
December 4-6 at Citilab Cornellà!
http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend
December 4-6 at Citilab Cornellà!
Truly, a new gaming platform is born!
The above was DrNokSnes running on a N900 :) Thanks to Konttori (author of the video also, thanks!), you can use a Wiimote to control it, even in N8x0! And of course, don’t forget to check the last seconds of the video for TV out and Wiimote control.
Very cool!
You’ll have to wait a bit until this version of DrNokSnes enters extras while I polish some of the rough edges ;)
I proudly present yet another Maemo port, DrNokSnes, which comes from DrPocketSnes.
It is capable of emulating Mode7 games like Mario Kart at 20fps with sound in your average N810, which is nowhere near full speed, but much better than original snes9x’s 2-3 fps (without sound!) and still very playable.
You can get it from extras-devel, and check development over at garage.
The biggest problem I found while porting opensnes9x ASM core sources is that it seems that the ABI the N8x0 devices follow mandates that the upper 16 bits of a register holding a unsigned short parameter value be set to zero. The ASM code doesn’t take care of zeroing those and as such random data was being introduced in the C functions, making those crash at weird points, or even worse, adding random behavior to the emulated games (man, seeing all the Mario kart characters keeping hitting themselves the whole race instead of racing was fun).
Also, I was bitten by a gcc bug; thankfully just switching the order of two statements (in the dsp1emu.c file) made the bug go away.
The port
uses SDL for its video, audio, input, and timekeeping functions. SDL
uses XShm in Maemo and I believe is the third fastest way to put images
to the N8x0 video hardware (first one being omapfb, second one being
Xv). Audio uses the SDL ESD backend by default; I found it works much
better setting buffer sizes <= 512 samples — same as what the SDL
ALSA backend “wants”.
I implemented snesadvance.dat speedhacks support into the emulator, since they’re becoming very common these days. Incredibly enough, I couldn’t find a single opcode 42 implementation for the opensnes9x asm arm core, so I had to write my own. It’s still incomplete and doesn’t handle most branch types, but it seems to work fine with my test rom set.
The GUI uses osso-games-startup. I don’t know why I decided to use it (probably because I like integration with the rest of the system), it’s a bit undocumented and has some “wtf” features, but I like the result.Many thanks to the original authors of DrPocketSnes and all of #maemo, who helped me a lot with the port, and enjoy!