Homebrew yuzu Nintendo Switch emulator discussion

[Deleted member 388531]

Holy fuck that was fast.

 

[dpad_5678]

Literally got off my bike once I saw this, sat down on the grass with my jaw dropped. Not even kidding.

I look like an idiot in front of a major Street right now.

 

[tunip3]

Does anyone have a link to a build from a download service that works? The last place I tried to download had a dead link.

i fixed the one in my post and added nsos

 

[Deleted member 388531]

Building now, will post a DL soon but I highly recommend building yourself as it'll get out of date in a day or two.

 

[tunip3]

Building now, will post a DL soon but I highly recommend building yourself as it'll get out of date in a day or two.

already posted one

 

[Deleted member 388531]

already posted one

rip, any buildbot setup yet?

 

[JOHN30011887]

Great news, cant wait to try Bayonetta 3 out some day i the future

 

[Furoryan]

I'm working on a switch emulator since beginning of october.
After checking the code, I think I am in a more advanced state.
Just by example :

u32 ARM_Unicorn::GetVFPReg(int /*index*/) const {
UNIMPLEMENTED();
return {};
}

void ARM_Unicorn::SetVFPReg(int /*index*/, u32 /*value*/) {
UNIMPLEMENTED();
}

So, they don't have an implementation for the VFP...
It took me more than a month to implement a functionnal VFP (but not full), and some opcodes are really harsh to emulate, as ARMv8 is compliant with IEEE 754, but has some extra features...
Today, I'm able to run the majority of dumps inside the main function (which calls nnMain). (So I successfully pass .INIT and .INIT_ARRAY sections).
I have found some fields explanation.
For example, for the thread context, (http://switchbrew.org/index.php?title=Thread_Local_Storage), offset 0x08 is a pointer to the next Thread (threads must be chained link in one way or another). This information has been updated 2 days ago, but is incomplete. At offset 0x1C8, it is a reference to the Main Thread (the information is not yet filled on switchbrew). In fact, it's the only way to pass some code in Zelda BOTW and other games. I don't know how to contribute to switchbrew...
I have some problems with the memory manager. Every call to malloc/calloc leads to a null pointer, but I don't find a symbol to fill in the symbol tables. So I will try to overwrite the calls to these functions. (Zelda BOTW doesn't do dynamic allocations in INIT/INIT_ARRAY sections, so for this game I'm going to nnMain).

I expect to be able to get the first screen in one month or two...

For Yuzu, I really think the first release is too soon, the code looks really garbage... (lots of dead code, too many unimplemented things, etc..., but the code of Citra is not really good too, the emulator still runs at low speed for too many games).
Also, I'm seraching help to understand TLS_DESC relocation, I have relocated the first u64 with the function name, but I don't know what to do with the second u64. (ARM document "IHI0056B_aaelf64.pdf" is not really explicit). It concerns only a few games.

Sorry for my bad english though!

Regards,
F

 

[RedoLane]

NANI!?

 

[gdkchan]

I'm working on a switch emulator since beginning of october.
...
F

You shouldn't be relocating the NSO binaries yourself, the relocation/linking work is done by rtld. You only really need to start running rtld at 0x0, and it should relocate/link everything, as long your cpu is stable enough and svcQueryMemory is working correctly (since rtld uses that to find the segments on memory). Also not nice calling someone else code gargabe. I think its good to release it at the current stage to get as much help as possible.

 

[Nezztor]

Damn, first homebrew appears in the wild, then TX announces they have something in store, then fail0verflow too, this week a kernelhax and possible compatibility for all FW...
AND NOW THIS?!

Man, I wonder if Miyamoto can even sleep at night lately with all these wonderful things being released for the Switch, seeing how their so called most secure system to date got fucked up the ass. lol

And wait for pokemon or metroid release, they will destroy all security to the point we will have a new 3ds with HD graphics

 

[Edgy_Edge]

What is this name YUZU? Can somebody explain me?

 

[yardie]

What is this name YUZU? Can somebody explain me?

You could have googled it to figure it out. Why don't people like to use their heads nowadays???

Citrus junos or yuzu is a citrus fruit and plant in the family Rutaceae. It is called yuja in Korean cuisine context. Both Japanese yuzu and Korean yuja are cognates of Chinese yòuzi, but the Chinese word means pomelo.

 

[Edgy_Edge]

You could have googled it to figure it out. Why don't people like to use their heads nowadays???

Citrus junos or yuzu is a citrus fruit and plant in the family Rutaceae. It is called yuja in Korean cuisine context. Both Japanese yuzu and Korean yuja are cognates of Chinese yòuzi, but the Chinese word means pomelo.

From the name YUZU I couldn't even imagined it's a fucking lemon. I'd prefer something NX related.

 

[yardie]

From the name YUZU I couldn't even imagined it's a fucking lemon. I'd prefer something NX related.

It's in relation to the citra emulator...

 

[Hurtz007]

Dayum!... Looks like I know what to download after I'm done moving... Yuzu + rainway streaming to switch = SWITCHCEPTION!

 

[Furoryan]

You shouldn't be relocating the NSO binaries yourself, the relocation/linking work is done by rtld. You only really need to start running rtld at 0x0, and it should relocate/link everything, as long your cpu is stable enough and svcQueryMemory is working correctly (since rtld uses that to find the segments on memory). Also not nice calling someone else code gargabe. I think its good to release it at the current stage to get as much help as possible.

I have written my own minimal dynamic linker... So no rtld for me.
But I have found the code of rtld of FreeBSD : https://svnweb.freebsd.org/base/sta...lf/aarch64/reloc.c?view=markup&pathrev=317189

static void
188 reloc_tlsdesc(Obj_Entry *obj, const Elf_Rela *rela, Elf_Addr *where)
189 {
190 if (ELF_R_SYM(rela->r_info) == 0) {
191 where[0] = (Elf_Addr)_rtld_tlsdesc;
192 where[1] = obj->tlsoffset + rela->r_addend;
193 } else {
194 where[0] = (Elf_Addr)_rtld_tlsdesc_dynamic;
195 where[1] = (Elf_Addr)reloc_tlsdesc_alloc(obj, rela);
196 }
197 }
I have a rela->r_info which leads to a symbol with ST_TYPE=6 (that is, a TLS symbol). I have copied the address of the function to my equivalent of where[0]. But I don't know what is exactly where[1]. It seems to be NSO dependant (the obj). From what I have understand, the function generates an unique offset number to the TLS storage. And where[1] is the place for the argument to the function???


Sorry to have said "garbage", but their code really appears to me as a copy/paste from the citra code..., and it also emulates nothing...! I think a lot of people will said "Yeah, it's super, I can play SMO on my PC", and be deceived just after trying to emulate a homebrew...
I have started my project from scratch, and I think it's clearly better to understand everything (I must admit have copied some code from Mephisto, for the system calls).

 

[Edgy_Edge]

It's in relation to the citra emulator...

Ok I understand that CITRA was a codename or something like this for 3DS, but it doesn't mean devs should stick to the citrus family. Alright I think devs are the ones who should name it.

 

[Hurtz007]

@Furoryan have you released the source yet?

 

[yardie]

Ok I understand that CITRA was a codename or something like this for 3DS, but it doesn't mean devs should stick to the citrus family. Alright I think devs are the ones who should name it.

It's his emulator. He can name it whatever he wants. Why does it even matter????