Open Ted-bissada opened 2 years ago
i don't think the Vita can run 3DS games
i don't think the Vita can run 3DS games
It can.
I'd love to see this come through
if it is possible to run 3ds games because until now it has not been possible with those of ds? I understand that there are loaders but they are not optimized
This is not an emulator, the ps vita cpu is natively compatible with the compiled binaries for the 3ds cpu directly aka. the ps vita cpu can literally just run 3ds games the issue is everything else. So you would need a gpu translation layer and to replace whatever the 3ds uses to interact with buttons, touchscreen audio hardware etc. with the vita versions.
The ds is not compatible with the vita cpu like that so it would need a more traditional emulator.
(edit) The vita cpu is armv7 and has a compatability mode for armv6 that the 3ds uses.
I would like to play monster hunter of 3ds on ps vita
If we want there to be some incentive to work on this, we must contribute.
If we want there to be some incentive to work on this, we must contribute,yes
Though Vita and 3DS CPU's have similar structure, it would be like saying PC's can easily emulate XBox because they're both x86 structure, ex: you'd need more than a CPU. There would probably be an insane amount of work to be able to use 3DS game graphics and shaders. Maybe as much work as PSP games getting native resolution on Vita. EDIT: after some research, it might be possible to use the recent Vita port of OpenGLES2 graphics library for the 3DS's GLSL graphics https://www.google.com/search?q=glsl+vita
Anyone seriously looking to port this might also want to look at this discussion page: https://www.reddit.com/r/emulation/comments/8k08g4/why_is_3ds_emulation_on_arm_so_hard/
Yes it would be an immense amount of work, as far as i know the 3ds shader capabilities are limited to vertex with only fixed function capability on the fragment shaders level so maybe that can help simplify it but there would still need to be capabilities to translate those shaders to something the vita could use.
@Ted-bissada requesting source on the claim 3DS shaders are written in "something similar to asm". From what I read it was GLSL, which is covered in OpenGLES2 Vita, right?
When i looked into it nintendo was offering opengl for commercial software and i assume it supported glsl, and people where just using shader assemblers like this one for homebrew.
I think the point is moot anyways because the shaders will not come in games as glsl files but precompiled so they will still need to interpreted by the vita and then recompiled by the vita shader compiler. Unless i am greatly misunderstanding how this could work.
I was looking at this potential project from the perspective of Vita stuff running on Nintendo Switch (vita2hos). I know that vita2hos can only run some vita tests and not commercial games but it is a start.
Kinda curious, what would emulating the 3DS GPU entail? The Vita CPU's armv6 code execution mode seems like it would help offload the CPU stuff, but would the Vita GPU be powerful enough to translate all those 3DS shaders?
If we want there to be some incentive to work on this, we must contribute.
Im not very experienced in programming but im currently learning c#, is there anything i can do to help now or in the future?
Probably learning about what the Vita can do directly such as running armv6 instructions and maybe opengl and learning what needs to be emulated on the vita such as the two display outputs
https://github.com/ds84182/citra This fork of Citra, though outdated, attempted to implement native execution (see https://github.com/citra-emu/citra/issues/5005) and I think this focused on armv8 compatibility in 32-bit compatibility mode but evidently armv7, being 32-bit, will have less hiccups. Mind you, Citra is OpenGL 3.3 and recently 4.3, Vulkan is not on Vita currently and the chances are you'd have to rewrite some of the graphics emulation. Note that the idea of a 'trampoline' exists because of the switching of execution state, which is something we don't need to worry about in this case. If anyone would like to research this it seems like a good starting point to approach a 3ds 'loader'.
Lol, I just saw this thread linked on the henkaku discord. It is impossible to make "3ds2vita" the same way xerpi made vita2hos, for that retail 3DS games are non-relocatable and loaded at a fixed offset that Vita reserves for the kernel. You could catch aborts and override branches, but that would impact performance significantly, i.e. to the point where games basically become unplayable. Y'all can look up my (rem) convo with CreepNT on henkaku.
To elaborate on this, here's a list of a few non-trivially-solvable issues anyone attempting this will encounter:
Non-relocatable binaries with "wrong" base address According to https://www.3dbrew.org/wiki/Memory_layout#ARM11_User-land_memory_regions, 3DS executables are always loaded at address 0x00100000, and rem told me relocations are stripped. However, the Vita kernel reserves lower quarter of the virtual address space (0x00000000-0x3FFFFFFF) for the kernel. I haven't checked precisely when VA 0x00100000 would get used (if ever) but it's safe to assume it cannot be recycled for loading the 3DS executable. This means the binary has to be loaded somewhere else, which will cause DABTs/PABTs that need to be caught and handled (I don't have figures but aborts should be quite slow to take).
Hardcoded SVC
Unlike the Vita where all syscalls are imported via dynamic linking, the 3DS emits raw svc #SYSCALL_ID
instructions in the code flow. This is problematic because the svc
instruction cannot be trivially patched into a "jump to thunk" sequence. A solution to this problem would be writing a custom supervisor call handler that can distinguish between 3DS and Vita syscalls and redirect to the appropriate handler (custom 3DS handlers/native Vita handlers), but this is not as easy as it may look.
Finding other issues is left over to the readers as an exercise, the point is just to show this is much harder than "load .3DS in memory, jump, ??, profit" regardless of the Vita using an ARM processor.
Is it possible a program similar to PSX2PSP could be made but instead of PS1, it would be for 3DS, and it could offset every byte by enough that it wouldn't conflict with vita system calls?
funnily enough, people are working on this exact same concept, but its a vita loader on switch.
is it still developing?
Still in development?
Maybe this project has been set aside. I may be wrong I hear people talking about it on Reddit.
So... The proposal for the PS Vita to run 3DS still valid?
I don't know much about programming, but I have a question. Let's say this 3ds Game Loader ends up happening, how well would games like Monster Hunter, Xenoblade Chronicles, and Kid Icarus Uprising run?
It seems that a 3ds game loader for vita is technically possible although very work intensive. The 3ds has a great library but i would rather play the games on vita. https://en.wikipedia.org/wiki/List_of_Nintendo_3DS_games
Features such as ds back compatibility or the 3d screen will be impossible due to missing hardware. Normal 3ds games should be technically possible and maybe new3ds but i don't know about that.
The concept is similar to the multiple android vita ports or yoyo loader. https://github.com/Rinnegatamante/yoyoloader_vita