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.
I look like an idiot in front of a major Street right now.
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.
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
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
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.
And wait for pokemon or metroid release, they will destroy all security to the point we will have a new 3ds with HD graphics
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.
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).
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????
Similar threads
-
- Portal
-
- Portal
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
RedColoredStars:
There is an actual trailer with footage too. lol. Going to watch it tonight. Grabbed it from... a place. -
-
@
SylverReZ:
@Psionic Roshambo, JonTron's back yet again until he disappears into the void for another 6 or so months.+1
-
-
