Wii mode GC hypervisor/emu

Well here's the idea. The app would work something like a hypervisor or qemu with kqemu installed, hiding the extra hardware and clock cycles from the GC game, emulating the GC controller and memory card (maybe even the lan adapter, but not sure there's a point anymore), and maybe adding some extra graphics capability (standard emu filters, making non widescreen 3d games widescreen like some emu's can etc). It's a not a request as such, more me wondering if this could work before researching something that might already be known to be impossible, though I can't see why as running GC games in Wii mode has being proven to be possible if not really playable.

Thanks

I think you're asking for a GC Emulator. If so, the answer is: "No. Impossible" If not, then what are you asking?

Not exactly, you wouldn't need to emulate the CPU or other hardware, just the controller and memory card.

Edit: like I said, more like an hypervisor, just with some emu capabilities



Edited 1 time(s). Last edit at 07/16/2009 06:53PM by robotmenace.

So, sorta like a program that launches a gamecube game but remaps gamecube controls to Wii Controls and the GC Memory Card to an SD Card?

Yeah, that's the idea and would be the main focus if I try to do this. It would have to be done in Wii mode though to be able to use the extra hardware, and I think timing issues would stop the bluetooth adapter and SD card reader from working even if you could mpatch MIOS to not turn everything not GC off. That's why I came up with this idea as a bit of a workaround. It could also add cool things like save states, and cheatcodes (though I never use them that would be cool) without downgrading MIOS and trying to find the old hardware and disc.



Edited 1 time(s). Last edit at 07/16/2009 07:18PM by robotmenace.

This may not be related, but I once tried the "Wii Pad" hook in Gecko OS, and the Wii remote stayed on when the GC game was running.

well, MIOS is already some kind of hypervisor, in that it handles memory partitioning (when gamecube games access memory mapped devices) and CPU configuration.

For a real hypervisor running on PowerPC, I think games would need to be coded first with the hypervisor in mind, I don't think it's possible otherwise (or it becomes an emulator)

I also wonder if it was possible to run gamecube games in wii mode, but gamecube clock speed.

For this i have some questions:
1. What exactly turns the wii hardware off? I think i read somewhere that it is related to the clock speed, which would be bad.
2. Does the gamecube have an arm processor? If not, could the Wii, if it could run gamecube games in wii mode, use that as hypervisor or whatever?
3. Does the MIOS and/or BC do anything else than changing the clock speed, disabling hardware and running the main.dol/elf from the game? If not, wouldn't it be possible to run gamecube games without MIOS/BC by doing all necessary stuff in a loader?

I am interested in the last question as well.

Quote
WiiPower
If not, wouldn't it be possible to run gamecube games without MIOS/BC by doing all necessary stuff in a loader?

Is there any reason, why we can't load and execute GC code in Wiimode?

GC DI code uses completely different register addresses than Wii register addresses.(There may be other peripherals requiring patching.) Patching would be required for GC disc games to run. If someone could get GC discs to be read with a modified libdi,(orginal libdi reading GC discs produce unknown errors) patch DI register addresses references, and slow down the clock speed of the Broadway from Broadway, then in theory GC discs should boot fine in Wii mode.(The clock speed could be adjusted via Starlet and modifying MINI as well. Of course this homebrew GC disc loader in Wii mode would only work if adjusting the clock speed only adjusts the clock speed, not disable Wii HW...)

What does DI cover?
Disc Access? more?
Why speed down the clock?

Pardon my lack of knowledge.

Quote

What does DI cover?
Disc Access? more?

DI =Drive Interface
hardware is generally controlled through hardware registers that are mapped in CPU address space
Gamecube access the drive at a difference address than the Wii does and it access it directly (the PPC program writes the registers and trigger DMA operations itself)

Quote

Why speed down the clock?

Generally, all chips/buses use clocks derivated/divided from the same base clock
Some Gamecube games might not use video interrupts for synchronization but hardware timers instead. I wouldn't dare trying to play FZero GX 1.5x faster :-)

also, maybe because some Gamecube specifc hardware (EXI bus for Memory card ?) have clock speed restrictions

Quote

2. Does the gamecube have an arm processor? If not, could the Wii, if it could run gamecube games in wii mode, use that as hypervisor or whatever?

No, it doesn't: games run on PPC and access hardware directly through registers & direct memory access, it's simple monoprocessor architecture.
On the Wii, that's what the ARM program is meant for, it handles access to IO hardware for the PPC program.
In gamecube mode, I suppose address decoding is done somewhere so that access to the old addresses (DI but also SI for GC controllers) is remapped to new addresses.



Edited 4 time(s). Last edit at 07/20/2009 11:54AM by ekeeke.

Quote
ekeeke
Gamecube access the drive at a difference address than the Wii does and it access it directly

What does MIOS actually do to handle that?

Quote
ekeeke

Quote

Why speed down the clock?

Generally, all chips/buses use clocks derivated/divided from the same base clock

I thought, the Wii and the GC have the same base clock and only the multiplier is chnaged by BC.

Quote
ekeeke
Some Gamecube games might not use video interrupts for synchronization but hardware timers instead.

That would actually have been a good practice, but unfortunately, most games console games still use VSync :)

Quote
ekeeke
I wouldn't dare trying to play FZero GX 1.5x faster :-)

FZeroGX actually uses VSync. Playing it in 50 hz is like having an extra easy difficulty :D

Quote
ekeeke
also, maybe because some Gamecube specifc hardware (EXI bus for Memory card ?) have clock speed restrictions

I do not really understand.
All of the Gamecube Hardware can be used in Wii mode too.

Quote

What does MIOS actually do to handle that?

I have absolutely no idea, you would have to ask someone who already have disassembled MIOS
MIOS = Minimal IOS ???

Quote

I thought, the Wii and the GC have the same base clock and only the multiplier is chnaged by BC.

yeah, divided or multiplied, the idea is the same: I meant that all the chips probably use the same base clock as reference, that base clock being itself derivated from a master clock. That's just a supposition though, from what I've read and already seen in other systems.

Quote

I do not really understand.
All of the Gamecube Hardware can be used in Wii mode too.

you're right, I forget you can acces memory card in system menu
Again, that was only a supposition because hardware generally supports a limited clock range.
This is not very important though, the main reason is probably because of timers being too fast (I'm pretty sure many games are optimized for PAL and don't use VSYNC).
Anyway, even that can be properly handled if they are using some kind of low-level API to access timer (libogc already do this perfectly for example, calling sleep(1) will wait the same amount of time in both modes) so it can be something else, I really don't know but it sure is interesting subject.



Edited 1 time(s). Last edit at 07/20/2009 07:28PM by ekeeke.

Quote
yellowstar
GC DI code uses completely different register addresses than Wii register addresses.(There may be other peripherals requiring patching.) Patching would be required for GC disc games to run.

Possibly just the exception handler would be enough, trapping and remapping accesses to any addresses that need it. That alone might slow down the game enough to make up for the clock speed difference; if not, just patch a delay loop in somewhere.

Perhaps MIOS doesn't really disable Wii HW. Perhaps MIOS just sets some register for re-mapping the DI registers. Never mind, there seems to be NAND interface, AES, and SHA engine disable code in MIOS. It seems that the only Wii hw related code run on MIOS is the Wiimote disconnection code, and the Starlet timer thread/process code.(The Starlet timer IRQ is the only IRQ enabled in the ARM HW IRQ mask register.) There's some AHB register,(I'm assuming this can only be set by Starlet) that enables direct access of all Wii hw registers from Broadway, which are normally only accessible from Starlet. This register is mentioned on gc-linux.org.



Edited 1 time(s). Last edit at 07/23/2009 06:08AM by yellowstar.

Quote
WiiPower
I also wonder if it was possible to run gamecube games in wii mode, but gamecube clock speed.

For this i have some questions:
1. What exactly turns the wii hardware off? I think i read somewhere that it is related to the clock speed, which would be bad.

BC sets some flag, then loads and boots boot2. If this flag is set, boot2 adjusts the clock speed, and loads and boots MIOS. MIOS disables the Wii hw. According to bushing on hackmii, MIOS contains the GC IPL, and MIOS bootstraps the Broadway to run the GC IPL, which then runs the GC disc game. Here's my MIOS notes. Mostly C code of reverse engineered code. The NAND interface, AES and SHA engine seem to be disabled by resetting the interface/engines twice. It seems to be possible to enable the sensor bar and the disc drive LED from GC mode PPC, unless there's some block for GPIO from Broadway. Never mind, HW_GPIO_OWNER is set to zero, blocking Broadway GPIO access.(A few function calls before the bootstrapping function call.) [pastie.org]

Quote
WiiPower
3. Does the MIOS and/or BC do anything else than changing the clock speed, disabling hardware and running the main.dol/elf from the game? If not, wouldn't it be possible to run gamecube games without MIOS/BC by doing all necessary stuff in a loader?

Not sure. But with a modification of MINI, with an implementation of the code MIOS executes, it should work.(Replacing loading/bootstraping IPL with an MINI app just loading the apploader should work.) Mainly MIOS shutdown code via power button is missing from my notes. There might be GC mode related code in the thread code, other than IPL loading, so that would need reverse engineered to write an loader.



Edited 2 time(s). Last edit at 08/09/2009 11:04PM by yellowstar.

I noticed the system can reboot from GC mode back to Wii mode somehow as well. Pop out Mario Kart's disc at the title screen and hit reset, IIRC. Kicks you back to the System Menu.



Edited 1 time(s). Last edit at 07/25/2009 01:50AM by HyperHacker.

That's when launched from sysmenu, right? The old version of Gecko OS I have doesn't set some flag correctly and boot2 runs when shutdown, running sysmenu.(Dunno if the latest version fixed that.) This isn't really useful, it's just some reset, causing Starlet to run boot2 as when Broadway is initially powered off.
EDIT:
This is related to MIOS, it's not game specific. MIOS executes shutdown code when the POWER GPIO goes high, and when IRQ15 is triggered. The former calls reset(1), while the latter calls reset(0).

reset/LT_3c40
poke_hwresets_ppcbits();
LT_3e74();
*((u16*)(0x0d8b4026)) = 0;
udelay(100);
LT_3ed8();
HW_RESETS &= 0xff800fff;//clear bits 12 - 23
LT_37a4(1, 0);
u32 temp = HW_RESETS;
if(in_r0==1)
{
	temp &= ~BIT(5);//PPC1
}
else
{
	temp |= BIT(5);//PPC1
}
temp &= ~BIT(0);//SYS
HW_RESETS = temp;
while(1);

poke_hwresets_ppcbits/LT_2abc
u32 resets = HW_RESETS;
HW_RESETS &= ~(BIT(4) | BIT(5));
udelay(15);
resets &= BIT(5);
resets = (resets >> 5) << 5;
HW_RESETS = (HW_RESETS & ~BIT(5)) | resets;
return;

Edited 2 time(s). Last edit at 07/25/2009 07:16AM by yellowstar.

Quote
HyperHacker
I noticed the system can reboot from GC mode back to Wii mode somehow as well. Pop out Mario Kart's disc at the title screen and hit reset, IIRC. Kicks you back to the System Menu.

Gamecube games used to reset the hardware, when the reset button is pressed, while the lid is open.