C_boy has just completed a remake of "Lode Runner" for the Nintendo DS "Origin v1.0 Lode Runner" came out at the time on Apple II in 1983. This first draft contains the first 20 tables on the 150 planned.

Quote:
The first version includes only the 20
first paintings on the 150 scheduled

I tried to set up an engine displacement of enemies who looks like the original games, but without cracking, it is impossible.
I will need your help to test the tables and see if they are feasible with this engine, and modify if necessary

"Closed" the famous puzzle game for the DS is back with a new version by Cobain, the 1.6 that contains 1 new enigme by Cortes48, and an update of credits.

Quote:
Hi,
Closed, the fabulous, excellent, the brilliant, incomparable, the single set of riddles that everyone knows just taken over version 0.1. So in this version 1.6 there as a new conundrum Cortes48 and a total revision of appropriations.

UAE4Wii is a port of the famous amiga emulator UAE based on UAE4all from Chui.
Pressing home will bring the GUI.

Wiimote is used as the mouse but also as pad #1 and pad #2

A = Left mouse click
B = Right mouse click
1 = Fire button
+ = Quit when emulating

To come, a nice GUI with advanced functions, a virtual keyboard and surely an update of the UAE
base source code used by Chui for UAE4ALL for more compatibility.

MahJongg Wii is a Mahjongg solitaire tiles game written specifically for the Wii, developed with devkitPro tools and using the GRRLib for rendering, sndlib for music and sound, and wiiuse for wiimote.

v0.6 08/11/08
Download - Mahjongg Wii v0.6

Added versus mode!
Re-factored the tile selection processing and completed all coding around tile selection for both versus and coop modes
Added option to restart the game when paused or no more moves left
Added option to start a new game without going back to the menu when current game has finished
Changed so that if only two tiles are left which are on top of each other the game finishes
Fixed bug where tile placement algorithm gets stuck in an infinite loop when it cannot place all tiles successfully. Now if this occurs it finishes the shuffle and returns to no more moves mode
Alternated which pointer is drawn first every frame to not give the advantage to player one in two player versus mode
Added separate tile selections per player (this affects the co-op mode as well as the versus mode)
Added Hungarian, Finish and Swedish languages

Alrght, after a few weeks of nothing I finally got around to write a blog post again
This time I'm going to explain how I managed to get SDHC cards to work with the Wii's internal slot without requiring any patches to the IOS.

This front slot is normally accessed by the device node /dev/sdio/slot0 which directly talks to the hardware registers of a standard sd host controller - there is even a specification you can download and read that explains everything you need.
However, to simplify things a bit nintendo apparently thought that it would be a good idea to let the IOS handle the SD card initialization process which basically only consists of sending three commands to the SD card to get it into the right state. Next to those commands it also pokes some host controller registers in order to enable the power supply, setup a stable clock and enable some interrupts. Those things are basically everything needed to get the host controller and the SD card to a state at which it accepts just about every command - and this is were IOS stops its work. It pokes another memory location that allows the powerpc to directly send commands to the SD card by either using a ioctl for normal commands or a ioctlv for data commands, i.e. commands that require data to be transferred using DMA. The powerpc has to take care of the rest and send the SELECT and (MULTIPLE_)BLOCK_READ commands to actually read data from the card. This seems to be their idea of abstraction...

When you now insert a SDHC card and call IOS' reset function it just returns some error value: SDHC cards have a slightly different initialization process: After sending the "GO_IDLE_STATE" command you need to send another command to indicate that you know about SDHC and are going to use it. The next two commands are then very similar to the SDv1 initialization with one more bit set to tell the card (again) that you know about high-capacity cards. If you don't send the special "i know about sdhc kthx" (aka CMD8) command the card will just return an error when you send the next command because it thinks that it can't be used with this host.

Since the SDv1 and the SDv2 (SDHC) process is nicely documented in the SD host controller and the physical layer specifications it sounds like it would be trivial to just do it yourself on the powerpc. There are however two things that you'll have to take care of:
At first IOS won't allow you to just send commands to the SD card if you didn't successfully call the reset ioctl first.
The second problem is that the card does neither get power nor a clock and all interrupts - which are required for the sdi driver to fully work - are disabled before you called reset

Fixing the first issue seems to be impossible at the first look without a IOS patch because of the following check inside the driver that fails when the card wasn't initialized:

default_sd_command ; CODE XREF: sdi_main+4E0jBL do_something_init_maybeLDR R0, [R6,#8]MOVS R3, #0x84 ; 'ä'ADDS R2, R0, #0MULS R2, R3LDR R3, =sdi_structsADDS R1, R2, R3LDR R2, [R1,#sdi_struct.card_present_state]LDR R3, =0xFFFF0000TST R2, R3BNE default_sd_command_checks_passed ; only branch if "card initialized" bit is setLDR R7, =0xC1000004 ; error codeADDS R5, R7, #0STR R0, [SP,#0x68+var_4C]B ioctl_return_maybe
Patching this check out would be quite easy - just replace the BNE to default_sd_command_checks_passed with an unconditional branch to it. The problem is that this would force everyone wanting to use SDHC cards on his Wii to install a hacked IOS.
But after I took a look at something different I found a way to still send commands to the card: The code listed above is just present in the ioctl handler - the ioctlv handler doesn't do this check. It just checks the passed vectors and calls the do_send_command function that the ioctl also calls then. This gives use a simple way to just send commands even before the reset ioctl was called to the SD card: Just use the ioctlv and pass a NULL buffer with a 0 length and a block count of zero. do_send_command checks for those values and just thinks that you actually send a ioctl instead of an ioctlv and will happily send your command to the sd card because both ipc messages use the same function to handle the card commands (which just sets some registers and memory locations up and lets the interrupt handler do the rest then).

There still is one problem though: The SD card neither gets power nor has a stable clock yet while both are required to answer to commands and the interrupts in the host controller are still all disabled which would make commands fail too. But well, there also is a way around this when you take a look at the ioctls the driver provides. Especially the set_hcreg and the get_hcreg commands are interesting: They directly allow the powerpc to write to the sd host controller hardware registers. Together with its specification it is pretty