I recently (today as a matter of fact ;D) made a psp replay routine for my softsynth tracker program available here:

http://protrekkr.googlecode.com/

The tracker is tailored for much faster machines so this is more an experiment than anything else.

If you intend to use it to create music for the PSP you'd better go very easy on the dsp effects and channels polyphony, especially the flanger fx is a really heavy toll because the media engine doesn't have any integrated hardware sin/cos or pow instructions.

The replay routine of the tracker uses the 2nd processor so the occupation time of the main CPU is really minimal.

Samples depacking with the PSP codecs isn't implemented yet (so samples packing should be set to "none" in that case).

The tracker itself is open source and available on Windows, Linux and Mac OS X.

v1.90 released:

Quote:

- Added a scrollbar beside patterns.
- The tracker can now load all these .wav file formats (mono or stereo) :
- 8-bit integer.
- 12-bit integer.
- 16-bit integer.
- 24-bit integer.
- 32-bit integer.
- 32-bit float.
- 64-bit float.
- Added an option to render a module as 32 bit (float) .wav file.
- Inverted the right and left mouse buttons functions in patterns.
- Fixed an issue with the loop editor.
- Patterns now automatically scroll when using the right mouse button (also work when selecting a block).
- Added multi notes channels, they can be used to trigger several notes / track at the same time in order to make chords or to play several instruments in the same track and route them to the same row effect / dsp effect (thus allowing to considerably reduce the dsp usage and also introduce some modularity which could be useful, especially for the PSP replay).
Note that these channels are shared with the polyphony ones.
- Improved volume ramping.
- Keys repeat was disabled when editing note columns.
- Added LCTRL+TAB and LCTRL+LSHIFT+TAB to cycle through the notes of a track.
- Added LALT+A and LALT+LSHIFT+A to select one or all notes/instruments columns of a track.
- Modified the record function (for a better one, i hope).
- Some edition commands weren't working on last track.
- Midi channels polyphony implemented.
- Improved Mac OS X keyboard handling a bit.
- Compressor wasn't set right when loading .ptp files.

The game is a typical action platform game. It´s based in the Turok´s games what it appear in game boy/game boy color. The demo is short less than five minutes and in it I show how will be the final game.

--------------------------------------------
Wii2600 v0.1 release README
--------------------------------------------

Ported by raz0red
[http://www.twitchasylum.com]

--------------------------------------------
What is Wii2600?
--------------------------------------------

Wii2600 is a port of the Stella 2.7.2 emulator to the Wii.

Stella is a multi-platform Atari 2600 VCS emulator released under the GNU
General Public License (GPL). Stella was originally developed for Linux by
Bradford W. Mott, however, since its original release several people have
joined the development team to port Stella to other operating systems such
as AcornOS, AmigaOS, DOS, FreeBSD, IRIX, Linux, OS/2, MacOS, Unix, and
Windows. [http://stella.sourceforge.net].

--------------------------------------------
Current status
--------------------------------------------

Wii2600 is an ongoing work in progress. For the latest project information
please visit the following URL:

[http://www.wiibrew.org/wiki/Wii2600]

--------------------------------------------
Known issues
--------------------------------------------

Wiimote paddle support is a proof of concept at this point and as such is a bit
buggy. The range of motion is currently very small. You must have the Wiimote
aligned directly with the sensor bar.

--------------------------------------------
Installation
--------------------------------------------

To install Wii2600, simply extract the zip file that this README was
distributed with directly to your SD card (retain the hierarchical structure
exactly).

Cartridge images should be placed in the roms directory (wii2600/roms).

--------------------------------------------
Tearing, Vertical Sync, PAL/NTSC, etc.
--------------------------------------------

Without the use of Vertical Sync, 2600 games that scroll (Barnstorming, River
Raid, etc.) will exhibit tearing during game play.

The first time Wii2600 is started it attempts to determine whether your Wii is
running in PAL (50hz) or NTSC/PAL60 (60hz) mode. Based on this determination it
sets a default value for Vertical Sync.

NTSC/PAL60:

If Wii2600 determines you are in NTSC/PAL60 mode (60hz) it enables Vertical
Sync by default. This should work well for both NTSC and PAL games. PAL games
run fine due to the fact that they run at a slower rate than NTSC.

PAL:

If Wii2600 determines you are currently in PAL mode (50hz) it disables Vertical
Sync by default. The reason it disables this setting is to be compatible with
both PAL and NTSC games at 100% speed. Since the Wii console is syncing at 50hz
it won't be able to maintain the required 60hz for NTSC games and as a result
you will get garbled sound and slow video.

If you still want to use Vertical Sync, you can enable it via the "Advanced"
menu in Wii2600. PAL games will run as they were intended, 50hz at 100% speed.
Wii2600 also configures another setting "Force FPS" to "50 FPS" when you enable
Vertical Sync in PAL mode. What this setting does is control the frame rate
that games run at. Essentially what it will do is force all games (NTSC or
PAL) to run at 50 FPS. In doing so it also adjusts audio buffer sizes, etc. so
that you won't experience garbled sound. The downside is that NTSC games will
now run at 50 FPS versus their intended 60 FPS, so the games will run a bit
slower.

The real answer to resolve these issues is to add auto-frame skipping to
Stella. That is definitely something I will be looking to add in an upcoming
release.

--------------------------------------------
Controls
--------------------------------------------

Wii2600 menu:
-------------

Wiimote:

D-pad : Scroll
A : Select
B : Back
Home : Exit to Homebrew Channel
Power : Power off

Classic controller:

D-pad : Scroll
A : Select
B : Back
Home : Exit to HBC

GameCube controller:

D-pad : Scroll
A : Select
B : Back
Z : Exit to Homebrew Channel

Stella emulator menu:
---------------------

Unfortunately, at this point all navigation of the Stella menu is done via
the Wiimote without the use of motion controls. Thus, the '+' and '-'
buttons allow for tabbing through the different controls. Pressing the 'A'
button operates the current control, etc.

Wiimote:

+ : Move forward through controls
- : Move backward through controls
Up/Down : Scroll (when focused on a list or slider, etc.)
Left/Right : Page through list (when focused on list control)
Left/Right : Move between tabs (when focused on a tab in a dialog)
A : Operates current control (presses button, launch rom)
B : Closes current dialog
Home : Exit to Homebrew Channel

Classic controller:

+ : Move forward through controls
- : Move backward through controls
R Trigger : (Alternate) Move forward through controls
L Trigger : (Alternate) Move backward through controls
Up/Down : Scroll (when focused on a list or slider, etc.)

Double Dash Wii is a Boulder Dash Clone for the Wii

Tested on PAL (Supports widescreen), NTSC untested (please report!)

A few months ago we released a small, hidden channel called “DVDX” which essentially allowed homebrew to read DVDs on any Wii console without requiring hardware modifications. Since that release some things that you are probably all aware of have happened: Nintendo released an update that blocks the installation of fake-signed titles like The Homebrew Channel or said DVDX installer and we published a workaround for the Homebrew Channel one day later.

However, we did neither have the time nor the intention to release a similar workaround for the DVDX installer since there certainly are better solutions to this problem and because we thought we would be able to release BootMii very soon. This was apparently not the case because we are still working on BootMii today. The only solution to get DVDX installed was to use questionable methods that are normally only used by pirates and definitely not recommended by us or, given that you were lucky, to use comex’ installer while it still worked.

There still seems to be a demand for a working installer though and I therefore decided to port our method of installing The Homebrew Channel to the DVDX installer. While doing this the “advanced” and the “patchmii” installation method had to be removed. They wouldn’t be of any use anyways since there is no sane possibility to install a hacked IOS on an updated Wii. You can therefore only use this installer if you have a Wii without hardware modifications because it will force libdi to always use the so-called DVD video mode which is not supported by many modchips. I’m afraid that you’ll have to wait for BootMii if you have a modchip without DVD support and want homebrew to be able to read your DVDs and if you did not install a hacked IOS and DVDX previously.
Please note that this only is a temporary solution that was only released due to the high demand. It will be replaced with a better solution once BootMii is available.

Just download dvdx34.zip and extract it to your SD card. You should then be able to launch the installer from the Homebrew Channel.

From the checker statistics, we’re seeing about 10% of Wiis with the new boot1 (all newer ones). What will happen to those new Wiis that have it?

At first, BootMii will not be compatible with those Wiis. A modified boot2 will not run on them, period. However, there is a way of accomplishing some of BootMii’s goals on those Wiis, by installing BootMii as the System Menu’s IOS, or as an entirely separate IOS, for example. There are pros and cons to these options, and they’re not as good as installing BootMii as boot2, but they are possibilities worth exploring. We won’t support them when BootMii first comes out (lest we delay it even further), but one or more of them might come in the future.


Since people seem to love to compare Preloader to BootMii, I’m going to throw it in the comparison as well. Here’s a table comparing the following attributes of the four solutions:

Brick resistance: chances of it helping you if you brick your Wii
Update resistance: chances of surviving a Nintendo update
Update safety: chances of causing a brick when the Wii is updated in the future
Code execution: what kinds of code you can actually run with it
Complexity: how many things can go wrong while using it
Low-level install: how easy it is to install using a hardware programmer
Compatible with return: does “Return to Wii Menu” run it?
Note that the metrics on the table are mostly relative to one another. “Low” doesn’t mean crap, it means lower than “Medium” or “High”.

BootMii as (separate) IOS is a special case. It would be useful for people who want to use software designed to run under BootMii (that is, using custom ARM code, not IOS) starting from code under IOS, without regard for having it run on boot or brick-safety. This is basically a completely safe option, but also the least powerful one.

Brick resistance: BootMii as boot2 has high brick resistance because it _only_ relies on boot1 and boot2, which are in a reserved area of NAND. BootMii-boot2 will run even if your entire NAND Filesystem is hosed, and only requires the first megabyte or so of NAND to be intact (containing boot1 and boot2). BootMii as IOS does quite a bit worse, because it does require a sane NAND Filesystem, and also a sane enough structure that the original boot2 won’t choke on it. However, it doesn’t require any PPC code to run, nor does it run any additional drivers (for example, WC24), so some failure modes related to system files are eliminated. Preloader also depends on the System Menu IOS and runs on the PPC side, so it only saves you from brick problems that affect the System Menu (although these are pretty popular, so it’s still significant) - it won’t help for anything affecting IOS. Of note is that BootMii-boot2 doesn’t require anything on NAND that is dependent on your NAND keys, so the parts of NAND that are required are exactly the same (at least among Wiis with the same boot1 version).

Update resistance: BootMii as boot2 is likely to survive updates, because it’ll only be overwritten if boot2 is updated. Nintendo has never done that so far. BootMii as IOS would be overwritten with a System Menu IOS update, and Preloader would be overwritten with a System Menu update, both of which happen often and are pretty likely. Interestingly, BootMii as a regular IOS is more likely to survive, simply because it would be installed alongside existing software and won’t be overwritten by any update. None of the options will survive a targeted attack - this is just a measure of how likely a “normal” update will remove them.

Update safety: BootMii as boot2 is essentially 100% safe. This is because boot1 can’t be changed, so the only thing that will affect it is a boot2 update. This would remove it, but that wouldn’t cause a brick. The only way an update could brick a Wii with BootMii as boot2 would be due to a deliberate sabotage attempt by Nintendo (”if we detect bootmii, deliberately brick that Wii”), which won’t happen because they would likely be held legally liable for the damage. BootMii as an IOS, on the other hand, could cause a bad brick if boot2 is updated to check the signature of the installed System Menu IOS. Boot2 hasn’t been updated yet, so this gives BootMii as SysMenu IOS a slightly better chance than Preloader, which would suffer from the same issue if either the System Menu IOS or boot2 are updated to perform this check. Since BootMii as a separate IOS doesn’t participate in the boot process, it is obviously 100% safe (unless Nintendo does something stupid like crash if any unsigned software is found, but that’s not going to happen because it would cause legal trouble as well).

Code execution: This is pretty simple. BootMii lets you run ARM (Starlet) code, which gives you full control (including the possibility of running PPC code). Preloader just lets you run PPC code under IOS.

Complexity: BootMii-boot2 is very simple. It only depends (obviously) on boot1 and