News via http://ps3.gx-mod.com/modules/news/a...p?storyid=2284

Sbucon959 released a test version of FBANext, after FB Alpha (Final Burn Alpha), a multi arcade emulator based on the source code for Final Burn.

Features:

Support the following platforms:

- Capcom CPS-1
- Capcom CPS-2
- Capcom CPS-3
- Cellar
- Neo Geo
- Sega System 16
- Toaplan
- Taito
- Psikyo 68EC020

Although this is a test version, Sbucon959 indicates he could play different games so perfect (full speed and sound).

Use:

- You must put your roms in the / FBANext-ROMS / on a USB / USB Drive

Controls

SELECT - Insert Coin
START - Start
L2 - Back to Explorer

PS3 FBANext-R364

Official site: https: / / code.google.com/p/fba360 /
Listen
Read phonetically
Dictionary - View detailed dictionary ...

News via http://mobiles.gx-mod.com/modules/ne...p?storyid=9409

According to the sign GAME Australian Nintendo 3DS future would indeed be sold at nearly 300 euros in the West. Mere speculation or concrete info?

It remains for Nintendo to announce the price of its Nintendo 3DS outside Japan, and even further afield also its release date western still not revealed. For the Japanese archipelago, is very clear, it will be available February 26, 2011 against 25,000 yen, or 220 €. A cost that we already seemed important, but the Australian site of the sign GAME has even worse to teach us.

Nintendo 3DS is indeed listed at 398 Australian dollars (prices do that for Internet sales), what makes us close to 300 euros or 289 euros if you want a precise figure. We are generally accustomed to pay a little more expensive than the Japanese, but here, hard to believe our eyes, yet open.

Two things: either GAME has reliable information that we are unfortunately not yet received, or it is just a guess. But in this case, when one chooses to better estimate the price of a machine, it tries to find one that tries to suit both the builder and the consumer, right?

CAUTION, as usual, this type of news is to be taken lightly! ...

[Alex] wrote in to let us know about this Kinect controlled LED wall that was whipped up at the Tetalab hackerspace in Toulouse, France. The wall, which was built earlier in the year, uses some MAX7313 LED intensity controlling shift registers. Each gets its own board and controls the intensity of sixteen different red LEDs. They’re embedded in the wall module and covered with ping-pong balls as diffusers.

The recent activity on the project takes advantage of the Xbox Kinect. As you can see in the video after the break, they’ve used the open source Kinect drivers to capture 3D environment data, processing it into color gradients which are displayed on the Pong wall. Shouldn’t be long before they someone comes knocking on their door to install this in a dance club. We love the effect, especially because it works in a dark room and the LEDs don’t cause any interference with the video capture.

http://hackaday.com/2010/11/21/led-w...t-join-forces/ ...

News via http://emu-russia.net/en/

CaH4e3 released a new version of his FCEU MM (NES emulator with improved mappers support based on FCE Ultra). Changes:
- mapper 25 - game bug fixed lol, ganbare goemon gaiden credits now works fine finally ;
- mapper 69 - debugger crash fixed;
- mapper 253 - fixed somehow, but I'm sure not ideal;
- UNIF OneBus - parent for UNIF DANCE board now, without PCM samples, emulation improved, new dumps working too;
- UNIF WITG - removed, dupe 193 mapper.

news source: http://cah4e3.shedevr.org.ru ...

Pate has posted more WIP News of his Dos emulator for the DS

Since last weekend I have been working on the I/O port handling and other things that already exist in DSx86 but which I had not ported over to DS2x86 yet. When I got DS2x86 running, I wanted to immediately start working on the protected mode stuff, so I left a lot of code commented out. Now I thought is a good time to port this code as well, so that DS2x86 could run most of the same games that DSx86 runs. I got most of the EGA/VGA port addresses done, and then also coded the MCGA graphics support, so that Wing Commander II will progress up to the part where it attempts to play digitized sounds.

After I had coded the straightforward MCGA mode blitting (where only a 256x192 window of the original 320x200 screen is converted to 16-bit color and copied to the DSTwo SDK internal buffers), I thought that this might be a good time to look into improved screen scaling methods. Many users of DSx86 have requested a smoother screen scaling method, but I have not yet added that as it needs going from the 256-color palette mode to 16-bit color mode. Now with DS2x86 I need to use the 16-bit color mode in any case, so this is a suitable test bench for the better scaling method.

The biggest problem with the more advanced screen scaling methods is that they are quite expensive computationally. The direct palette conversion code is reasonably straightforward, it just needs an extra table lookup to convert the palette index to a 16-bit color that can then be written to the output buffer, like this (shown for a single row):

la v0, BG_PALETTE // v0 = address of the palette table
1: lbu t3, 0(t1) // Get a byte (palette index) from VGA VRAM
addu t1, 1 // Increment input index
sll t3, 1 // Palette table has 16-bit values
addu t3, v0 // t3 = pointer to the palette table
lhu t3, 0(t3) // Get the 16-bit color from the palette table
addu t0, 2 // Increment output index
sh t3, -2(t0) // Store the 16-bit color to output table
bne t0, t2, 1b // Loop until one row done


However, even the simplest smooth scaling method, linear interpolation, needs a division and two multiplications per pixel. I am actually not sure how many CPU cycles multiplications and divisions take on the MIPS processor of DSTwo, but I assume they are more expensive than normal additions and subtractions. In any case, I used a calculator and some experimenting, and noticed that what I actually need is a way to smoothly draw 4 output pixels for every 5 input pixels (as 320/256 = 5/4). So, I have only four separate cases, and in fact the two rightmost output pixels are mirror images of the two leftmost pixels, so actually I only have two different cases. I was sure that I can come up with some shortcuts for these two situations, so I began to look into these more closely.

Linearly interpolating over 5 input pixels showed that the first output pixel should have a color of 80% of the first input pixel and 20% of the second input pixel. The second output pixel should have 60% of the second input pixel and 40% of the third input pixel. Mirroring these, the third output pixel should have 40% and 60%, and finally the last output pixel needs 20% and 80% weighting of the colors. To get rid of the divisions, I looked into multipliers that would let me divide the result by a power of two (so that I can use a shift instead of division). The first 80%/20% case is pretty close to 25/32 (78.125%) and 7/32 (21.875%), and the 60%/40% case is close to 5/8 (62.5%) and 3/8 (37.5%). I coded the first version of a linearly interpolating scaling code using simple shifts and additions to handle this pixel weighting, and I thought the result looked satisfactory, especially as the pixel weighting percentages are not quite correct. The code did not seem to cause any noticeable slowdown, even though it is still far from fully optimized. Here below are screen copies of the zoomed and scaled versions of the same Wing Commander II title screen.


Next I plan to start looking into the audio support. The whole audio playing technique in the DSTwo SDK is still completely unclear to me, as I haven't looked into it at all yet. That is the biggest feature still completely unsupported, so it is time to start working on it.

http://dsx86.patrickaalto.com/DSblog.html ...

News via http://dingoonity.org/

FCEU320 with autoframeskip has been updated again! This emulator just keeps getting better and better!

Quote
v0.3 is here!
changelog:
* added button X to exit the emulator in file browser(exit in menu is not implemented yet)
* GUI is now on the POWER button, not on L
* L is now "load state 9"
* R is now "save state 9"
* updated mappers and boards
enjoy! ...

Yep you read right, theres a new release of the only active Nintendo 64 Emulator for the PSP.

Heres whats new:

What's changed in this revision:
Revision 601
Revision 600
[+] Small speed up in DList processing (Corn)
[~] Fixed daedalus profiler to profile Ucodes properly (Corn)
[~] Fixed missing preview msg in classic GUI (Corn)
[+] ScreenShots will be saved in ms0:/PICTURE for release and default dir for debug build
[~] Fixed issue that caused gui selection not be saved in preferences.ini
[~] Small clean ups, made a couple of funcs debug only, etc
[!] Corrected regression that messed up the penguins in M64
[~} Corrected regression that caused analog stick to stop working (thx KingPepper for reporting)
[!] Optimized intraFontGetID, uses about 70% less cpu (gui feels smoother now)
[~} Corrected overlapping text when psp is charging in bat info
[+] Changed how button polling in GUI is done, now is only done in one place instead of zillion times everywhere ( note : gui buttons now will be only checked 16.5 times/sec too) (Corn/Salvy)
Revision 599
[!] Made kernelbuttons even more robust
[!] Removed a bunch of hacks I had for KernelButtons (no longer need 'em)
[+] Implemented a wrapper for kernelbuttons to clean up code and make things easier
[~] Minor tweaks on the battery info when PSP is charging (psppwner300)
Revision 598
[+] Made rom deletion more robust, now rom list is refreshed. warning shows up before deleting, and deletion is canceled if other input is detected (Classic Gui recommended) (Corn)
[+] Is now possible now to reset only settings or only hle caches (Corn)
[!] Killed a couple of warnings from last commit (Corn)
[!] Improved Reset settings instructions, just follow the onscreen indirections.
[+] Added a new function to print intrafont text (pretty easy to use and can be used everywhere)
[!] Battery status and time is printed with intrafont to match with the Gui
[~] Improved GUI switching
[~] Corrected typo that prevented gprof build from compiling
[~] Removed debug info that I forgot from DeleteRecursive (debug build compiles again)
Revision 597
[+] Added build support for psp gprof (Thanks Hardhat for the help!)
[!] Cleaned up global prefs, also made "skip splash screen" and other prefs debug only
[!] Improved "Reset Settings", now is more robust and friendly (moved to global too)
[+] Implemented recursive deletion, hle cache is now deleted when resetting settings
[+] Implemented tooltips with usage info of features of the emu (only for Classic GUI) (Corn)
[~] Moved PSP Slim cache init out of initialization list

Warning : Make sure to back up your memory stick before using this revision.

http://forums.daedalusx64.com/viewto...t=2640&start=0

Those wanting to try an alternative PSP N64 Emulator can also try out Monkey 64 --> http://psp-news.dcemu.co.uk/emulator...psp-35150.html ...

The PSP Emulator for Windows has seen yet another release, heres whats new:

Partially implemented sceVaudio module.
Exported "Impose" and "System Param" settings to a new "Region" section in SettingsGUI.
Fixed VPL freeing in SceKernelVplInfo.
Properly implemented error handling for savedata MODE_SIZES in sceUtility.
Added new findings to sceAtrac3plus and sceSasCore.
Added drafts for missing sceAtrac3plus functions and implemented sceAtracSetAA3DataAndGetID.
Improved sceAudioSRCOutputBlocking.
Improved communication between scePsmf and sceMpeg modules.
Improved sceRtcTickAddMonths and sceRtcTickAddYears.
Updated all language files.
http://buildbot.orphis.net/jpcsp/ ...

Apple's (as yet unconfirmed) plans to make an iPhone with a built-in, programmable SIM chip is getting a strong push-back from European carriers who would have the most to lose from the shift away from physical SIMs. The Financial Times of London reports that carriers are saying Apple may provoke a "war" if they pursue this technology, and that they may decide to just stop offering iPhone subsidies in protest. Meanwhile, the industry group representing carriers is working on its own embedded SIM.

As we reported a few weeks ago, Apple is said to be working with SIM-card manufacturer Gemalto to make a programmable SIM-on-a-chip that would let consumers buy a phone directly from Apple and activate it with the carrier of their choice via iTunes.

http://modmyi.com/forums/iphone-news...built-sim.html ...