New from Larbi



Hello
check out this math game I made using Palib. it is my first DS game. I wrote it to help my son improve his math skills, addition, subtraction and multiplication to be more accurate. it works on any emulator but plays better on the DS. the handwriting recognition is better with the stylus.

The game can be downloaded from here : http://ndsmath.blogspot.com/

Download and Give Feedback Via Comments ...

Lino has released a new pre alpha version of fb4nds - Facebook for Nintendo DS, new for this release is the sending of messages:

Download and Give Feedback Via Comments ...

News via http://www.wii-addict.fr/forum/WiiXp...01-t18282.html

Updating rev101 in the file explorer on the Wii made by dimok and r-win.
Forwarder v3 always available

You can delete, rename, copy / paste / cut and see the properties of files on your SD or SDHC card.

QUOTE
* R101
- Fixed exchange of DVD being remounted
- Moved DVD mount to mount only when the DVD Icon is clicked when devicemenu is not loaded
- Fixed D-PAD after scroll
- Fixed Properties on RightClickMenu being off screen
- Pictures Made up fullscreen at startup when they are over the size for better SlideShow
- Some more minor bugfixes

* R100
- Fixed WiiXplorer not returning to SYSMENU when started with Forwarder
- Changed Forwarder and app entrypoint (Sorry dj_skual'll have to reupload a new channel the old one will not work anymore)
- Compiled and uploaded new Forwarder.dol (the old one will not work anymore)
- Changed the way DOL / ELF booting is working completely. Now almost all Homebrews should boot, this includes WiiXplorer booting itself up again
- Minor fixes

Download and Give Feedback Via Comments ...

Marcan is back with a rather long post over at Hackmii:

Wow, time does fly. More than a year ago, on October 23rd, 2008, Nintendo finally released an update that fixed the strncmp (fakesigning) exploit in all forks of IOS. This disabled any direct methods to install unofficial content on all updated Wii consoles. At the time, version beta9 of The Homebrew Channel had been in the making for a while, so we decided to take the opportunity to use one of our stockpiled IOS exploits to work around the update and release beta9. These exploits differ from fakesigning in that they directly exploit the IOS runtime, injecting code that lets us take control and disable signatures altogether. Therefore, this was our first released IOS code execution exploit. HBC beta9 was released and worked great on all Wiis, as always.

In order to hinder Nintendo’s attempts at fixing it, and to avoid misuse by warez kiddies, sven and I had a lot of fun obfuscating the exploit over a couple afternoons. We decided not to release information about it, hoping it would last long enough to be useful for future installers and BootMii. Later we kind of forgot about this, but on a few occassions people have asked us to document it, and we proposed a challenge: we would document the exploit as soon as someone “broke” our obfuscation and figured out how the exploit works. The intent was to promote reverse engineering and also see just how long it would take people to crack it. Apparently, either people weren’t very interested or we did a pretty good obfuscation job, because it took pretty long

Well, I’m happy to say that today I received an e-mail from an anonymous hacker who successfully reverse engineered our layers of obfuscation. He (or she!) discovered the inner workings of the STM Release Exploit, as I will be calling it, and did so after three weekends of reverse engineering. Hats off to you, and thank you for taking the challenge!

This bug was discovered by accident, and in fact it is a real honest-to-goodness software bug that is not only exploitable, but a nuisance during regular use. To understand it, you need to understand how STM works.

STM is the IOS module in charge of random hardware functions such as handling the fan, “idle” (WC24) mode, the front slot LED (including the blink patterns), and the buttons. I have no clue what STM means, but I’ve seen it called “State-TM” somewhere on the Wii. One of the main functions of STM is to provide a way for PowerPC software to get notifications when either the Reset or the Power buttons are pressed. It’s worth noting that I have no clue why they did this –the PowerPC already knows about Reset via the legacy GameCube interface, and can be given direct access to Power including IRQ via the shared GPIO system, and IOS doesn’t use these buttons at all– but they did. It works like this: STM creates two devices, an “immediate” device, and an “event” device. The immediate device is used to issue commands to STM that take effect immediately, while the event device is the callback mechanism. The PowerPC code issues an IOS_IoctlAsync() call on the “event” device, and this call blocks (asynchronously) until there is an event (such as a button press). When this happens, the call returns with the event code, and the PowerPC code reissues it to listen for further events.

One problem with this approach is that the PowerPC needs a way to shut down the event callback. The IOS IPC mechanism doesn’t provide a way for the PowerPC to cancel an ongoing request; it must wait until its completion. When PowerPC code needs to hand off execution, it needs to clean up all references and file descriptors to IOS, so it needs a way to get rid of the event call. STM implements this by having a call on the immediate interface that forces the event call to return with a zero event code. So far so good. If you’re interested, check out stm.c on libogc (particularly the functions with EventHook in the name).

Full article --> http://hackmii.com/2010/01/the-stm-release-exploit/ ...

News via http://www.open-pandora.org/index.ph...emid=2&lang=en

We've learnt something. Chinese English and English is definately not the same.
Good thing a friend of Fatih does speak Chinese. For the company, he's now our official represantative. As he could speak with them in their native language, a lot of things cleared up.

When they were talking about "soon", it didn't mean what we did understand as "soon". "Soon" did mean "as soon as we're finished.". Regardless, how long that will take. So each time they said us "We'll soon have pictures", we assumed they will follow the next few days - which didn't happen.

Another thing we found out is when they said "We're finished and will do some testing injections", they didn't mean they were finished with ALL our changes, but they finished ONE thing on the to-do-list and did a test injection to see if that was fine. That's why we got some shipping dates which never happened - and with us wondering why they didn't tell us. They sent us emails with stuff like "We fixed it all and will do the next samples on Friday". We then thought, okay, the next samples will ship on Friday. However, as we now do know, it meant they finished another step on those days and made an internal testing injection to find out if everything is okay. It wouldn't have made sense to ship us those half-finished cases (it would just have cost a lot of money). And that's the reason why they didn't tell us that they didn't ship... they never planned to ship it


It's really interesting what can happen if business partners do speak completely different languages as native language.

So much for the background "What happened". Now onto the more interesting stuff: What WILL happen?

One thing we did understand correctly was that their goal is to have the mass-produced cased finished and shipped until the chinese new year!
We now do know that they did finish the last tweaks on the case mould, the silkscreen and the keyboard mould (which still had one mis-aligned letter). And with finished, I do mean REALLY finished. Not just another step, but all steps. This does mean they'll ship the final samples within the next days. They are VERY positive they are perfect, so as soon as they shipped out everything, they prepare the mass production. So as soon as we get the samples and approve it, mass production will start. As they can produce 1000 cases a day and we need 4000 for the first batch, this can happen within four days. That should work out just before the chinese new year!

I know it does sound a lot like stuff you already heard before - but this time, we were talking with them in their native language, so I assume it will be much more accurate than anything before! ...

News via http://www.open-pandora.org/index.ph...emid=2&lang=en

Nope, we're not playing Lemmings, but I guess a lot of you wanted to know what happened to those cases.

Well, we too wanted to know - the last status update we had was that they were shipping on January 15th and therefore we assumed the cases should have arrived last week.
Unfortunately, Fatih had business to do in Dubai... and he is the only one the Chinese actually do talk to (except for if they encounter any problems, then they also send a mail to Michael. But they didn't do that).

So we didn't know until he returned a few days ago that the cases hadn't been shipped yet, they were still working and tweaking as they really wanted to make sure this will be the last case they need to send to us before we start the mass production.
We're still trying to find out the complete story of what happened and why there was another delay. A friend of Fatih (who can speak chinese) will help us here, as communication with them isn't easy, and there might even have been some misunderstandings, etc.

Whoever does think that that company is a small, cheap company that only tries to rip us off:
Nope, that's definately not true. Fatih has been working with them since years. Also, they created some other parts for the Pandora which have been finished long ago and didn't make any problems. It just seems the case was much more complex than they had thought.
Some of their other customers are Sanyo and Toyota and they have been established 1998, so one thing we know: They are reliable... but (as it is the case with many chinese companies): They do need some time to finish it off.

So, rest assured, the cases aren't screwed, we just don't know yet when exactly they will arrive. We have been promised they will ship enough mass produced cases before the chinese new year. I leave it to you whether you want to believe it or not - I just will pray it will be true.

So much for the cae situation. I hope you can now understand why we chose that company. Believe us, it's a pretty annoying feeling having everything setup for mass assembly and then wait in anticipation for the cases.

Oh, I have one more information that will probably make second batchers happy: We already ordered the parts for the second batch to decrease the waiting time.


Finally, some small OS informations:

* We got a new WiFi driver, thanks to Palm We'll need to test it out more, but it should work better than the one we have.
* pmenu is finally working fine in the image, so we have an almost completely working image (for a first release) ready.
* We also did a quick try with the Ubuntu netbook-launcher-efl. It compiled and worked nicely. Only the icons were missing, but that's because it uses the Human icons from Ubuntu which we haven't installed yet. The nice thing about it is that it does support finger scrolling. It might not make it into the first release, but I doubt it will take long until it will be included into an update. I personally prefer XFCE4 and pmenu though ...

Newly released for Dingoo:

This unbricker tool is patched up so that the unauthorized screens don't come anymore. You should all thank MTH on #dingoonity (freenode) cause he basically read the mips code i disassembled. I only patched an unbricker tool and did some research.
It has been tested on bricked HK models and found to be working by diffrent users, more info here : http://boards.dingoonity.org/dingoo-...r-flashing/45/

http://dl.openhandhelds.org/cgi-bin/...0,0,0,0,15,256 ...

News via http://www.summeli.fi/?p=1475

I decided to build a two threaded application. The main thread is for the UI, and the worker thread if for the emulator. This makes all porting easier in general, since now we can have a UI thread to handle all rendering, key I/O etc, and run the emulator thread as worker thread, which can emit the new processed frames to the UI thread etc.

The Qt makes the threading extra easy:
In my application I just inherited the emulator controller class from QThread, then I just call start() to start the thread. The QThread will guarantee that all slots will be executed in the context of that QThread after start has been called.
Another nice trick is to use Qt::BlockingQueuedConnection as connection type when the signal must be prosessed before the emitting thread can continue.

I’m really excited that all this communication between threads was so easy. No mutexes, or semaphores were required this time at all ...

News via http://dingoonity.org/

Vinicius(cabelo) has scripted another interesting tool for ports and emulators that require a lot of RAM. MicroMenu, a front-end to execute heavier ports without the need of Dmenu or Dinguxmb


Quote
To install, just replace the 'main' file on local/sbin. Check if the path and binary files are right (remember that on *nix systems the names are CaSeSeNsItIvE).
To choose, use DPAD and START.

To use other itens on MicroMenu just edit the main and set the right path/bin. You can?t use any port that uses the file selector(like snes9x)

Download link(100126): http://viniciusrezende.com.br/pub/di...enu_100126.zip
DingooBR post: http://www.dingoobr.com/?p=1265
More info about download and instalation instructions: http://viniciusrezende.com.br/pub/dingux/micromenu
(News are comming, the dpad is a temporary solution)

Thanks to zolini for the news and the Dingoo Brazillian community.

Official Release post is here: http://boards.dingoonity.org/dingux-...nu-for-dingux/

Download and Give Feedback Via Comments ...