Apparently some people have managed to get the java based NESCafe emu running on the Xbox 360 through it's media center.

Xexter from xbox-scene.com explains the method:

I've attached a link to a version of NESCafe that works through Media Center on the Xbox 360. This is currently setup to run at 480p (Widescreen). You can edit the nes.htm file if it does not fit correctly on your screen. I haven't found a way to add a menu for the roms list so you will have to edit the nes.htm and change <param name="ROMFILE" value="/roms/whateverrom.zip" /> to whatever Nes rom you want to play. I've included a Public Domain rom for testing but have verified Zelda1-2, Excitebike, and TecmoBowl and all worked.

Please do not ask for ROMs as they are quite easy to find (Google - "Nes Roms"). 

 

DOWNLOAD RAR: http://www.yourfilelink.com/get.php?fid=58730

 

 

INSTALL:

You will need to extract the rar into C:Documents and Settings\All Users\Start Menu\Programs\Accessories\Media Center\Media Center Programs\ on your media center box. It took a bit for the icon to show up under More Programs but it finally will.

 

NOTES: Sound is not functioning, Media Center 2005 is required. If it locks up you will need to run something that warns you that it is a web page and check the box that says "Don’t show this again". Once you do that it should run fine. I created an MCL that just went to Google and then checked that box. I've also attached an image with the mapping of the Xbox Controller to the corresponding keyboard keys.

 

-X

Download Link

Video of it in Action

Controller Mapping

2006-03-28

 

* GPU:  Added support for the A3I5 and A5I3 texture formats 

* GPU:  Fixed some errors in color selection for paletted textures 

* MMU:  Upped the FAT limits to max 32768 files/directories with a total size of 256 MB 

* MMU:  Added support for long filenames in the FAT 

* GUI:  GBAMP emulation can be turned off (on memory tab, or in dualis.ini) 

* GUI:  Switched from WM_TIMER to a multimedia timer callback 

 

Note that the max number of directory entries at the root level still is 512, and that the max total number of files/directories will be lower than 32768 if there are files that uses long filenames.

>> Get it HERE.

27th March 2006

RPCemu 0.4 released.

 

Changes since 0.3 :

 

* Fixed stupid bug with flyback bit in IOMD control register - RiscOS 3.x now starts up correctly every single time (why did XXXX X work?)

* Rewritten video emulation - now supports 16-bit & 32-bit colour, has correctly coloured cursor, some video acceleration, etc.

* HostFS - allows access of the Windows filesystem from RISC OS

* Now supports 2 hard discs

* Now supports >16 megs RAM, and VRAM

* Now licensed under the GPL

* Preliminary Linux port, thanks to Peter Naulls

>> Get it HERE.

VL_tone at Acmlm's Board

has released a Super Mario 64 rom Extender and he says:

After some delays, at last I'm releasing the Super Mario 64 ROM Extender!

 

 

Yeah, not only it's not a very original name, and it doesn't exactly convey it's real use.

 

This program will produce a usable decompressed version of the Mario 64 ROM. It means that instead of struggling to fit re-compressed edited data in the ROM. The decompressed data inside the extended ROM can be edited directly, and it can run as is in an emulator.

 

Note: This is not a level editor.

 

You can download the Windows version at:

http://rapidshare.de/files/16368233/M64ROM...r_1.1b.zip.html

 

And the Mac OS X version at this url:

http://rapidshare.de/files/16430880/M64ROM....1bMac.zip.html

 

Here is in geekier terms what it means: (Copy/paste from documentation)

 

What this program will do:

1. Swap bytes if a.v64 version is provided. The output file is in.z64 format (ABCD byte order)

2. Extend the ROM to 24 megs, by adding 16 megs of "FF".

3. Decompress all the MIO0 files in a directory named "MIO0files".

4. Copy the uncompressed data in the upper 16 megs of the extended ROM, leaving 32k gaps between data segments.

5. Change pointers to match the decompressed data.

6. Recalculate the checksums.

 

What this program won't do:

 

1. It doesn't work with European and Japanese versions.

2. It won't work with ROMs that have a byte ordering other than ABCD or BADC.

3. It doesn't make Luigi a playable character.

4. The extended ROM won't run on an iPod. (Ok that's a lame joke.)

 

 

 

The program is straightforward. Click the Open ROM button, chose a.v64 or.z64 US version of Mario 64. Wait until it's done (a few seconds only) and there you get a 24 megs version of the ROM, with.ext.z64 appended.

 

Ultimately, this ROM format will be used by my Super Mario 64 Level editor that will be released later this year. But until then, it can have many uses.

 

The documentation includes a list of where the MIO0 files are moved/decompressed.

 

Even if you are a newbie, you can make some good use of this program if you know how to use a graphic/tile editor.

 

Tile Molester will open the extended ROM and enable image viewing and editing, if you set it to RGBA 5551. You'll have to find the textures yourself, starting at 0x800000 in the ROM.

 

The first part at 0x800000 also includes the game text. I may provide a text editor soon.

 

I wouldn't mind at all if someone would host the Windows version somewhere, and if anyone wants to make a smaller version of this ROM extender, just PM me, I'll provide the details.

 

 

--------------------------------------------------------------------------------

 

 

Some people in the past argued that it would be best to only move compressed data after the end of the ROM, instead of being de-compressed, to save space...

 

I had a few arguments against it, and at least in appearance it looked like I wanted a decompressed version only because I had problems writing a fast compressor in Director. Now that I found I can call command-line utilities, this point is moot.

 

I still think it's a better idea to standardize around a decompressed format.

 

Why? I found some good reasons... Being able to use standard tools like Tile Molester is one. Also, anyone wanting to write an editor for Mario 64 wouldn't have to implement MIO0 decoding and encoding in their program. Other benefits include being able to generate standard IPS patches (Unless you put some padding, MIO0 files would move around when their compressed size change), and also generating patches without having to re-compress all the MIO0 data beforehand

check the thread for screenshots.