[ / / / / / / / / / / / / / ] [ dir / 3rdpol / bcb / cutebois / had / lewd / shota / ss / tacos ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Email
Comment *
File
Select/drop/paste files here
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 4fd308e805a3e3f⋯.jpg (17.48 KB, 582x437, 582:437, PS4-Pro-SOURCE-Sony.jpg) (h) (u)

[–]

 No.937268>>937279 >>937372 >>937376 >>937378 >>937383 [Watch Thread][Show All Posts]

The current generation of game consoles, PS4 and Xbox One, use x86-64 CPUs as well as non-custom GPUs which makes them very similar to PCs. Their graphics APIs are also extremely similar to DX11. I wondered whether it would be quite easy to run their binaries on a PC by writing a Wine-like compatibility layer instead of emulating the hardware. Turns out there actually is such a project at least for the PS4:

https://github.com/AlexAltea/orbital

So, what tasks does such a compatibility layer have to fullfil?

From what i understand its

<Correctly responding to / remapping syscalls

<Providing substitutes or "adaptor" includes that the binaries link against

For example, Wine needs to provide a substitute for kernel32.lib

So really, what else is there to do? Im sure it's a lot, or if not, that these two tasks are not as simple as i think they are.

 No.937279>>937296

>>937268 (OP)

It's been done before. There was an original Xbox "emulator" for Windows XP way back in the day that was essentially a compatibility layer.


 No.937282>>937577

PS4 runs a BSD variant on a slightly modified X86_64 architecture. It's nowhere as 'weird' as the MIPS processor + graphics chip combo found in the PS1. Of course it will be easier to 'emulate' than all previous systems. I wouldn't be surprised if you could run most PS4 code unmodified. There's bound to be a catch, probably due to the fact the CPU and GPU are integrated and share the same memory, but they will simply patch that.

This applies to the Switch and Xbox as well. The Nintendo example is literally off the shelf hardware. These things can barely be considered consoles. They're locked down PCs -- the only difference is you can't run your own programs on these machines.


 No.937296>>937370

>>937279

>There was an original Xbox "emulator" for Windows XP way back in the day that was essentially a compatibility layer.

I've never heard of a good Xbox emulator, do you remember the name?

>>937279

>I wouldn't be surprised if you could run most PS4 code unmodified

Yes, isn't that a given as it is the same instruction set? The only part that requires work is the compatibility layer around it, right?

>the CPU and GPU are integrated and share the same memory

It's not like iGPUs or APUs are unheard of. The PS4 has a Jaguar APU, and the GPU is a modified 7970M with more stream cores.

How do console developers work on these things by the way? Can they only develop on original / devkit hardware, or do they have proprietary emulators?


 No.937352

Just run the OS in a VM, done.


 No.937370>>937524

>>937296

>I've never heard of a good Xbox emulator, do you remember the name?

Cxbx. Don't get me wrong, it's by no means good. It only runs about 5 games. But as far as I know, it's still unmatched, even by its 64 but fork, Cxbx Reloaded.


 No.937372>>937374

>>937268 (OP)

The Xbox One gates all execution behind a hypervisor so that's already out. The actual execution environment of the Xbox One is more RISC-Like for security reasons and to simplify backwards compatibility with the Xbox 360

The PlayStation 4 does not use a standard platform hub. Instead using a separate ARM chip acting as a security coprocessor and North/South bridge. Its also missing many standard BIOS functions needed to just plop a regular kernel in-place

You could however, port a small Linux kernel to the PS4, then use it to chainload a custom hypervisor that implements standard BIOS calls, then load stock Linux or even Windows from that. But so far it hasn't been done. Probably because anyone who would otherwise care would probably just tell you to get a regular fucking computer


 No.937374>>937660

>>937372

I misunderstood OP. But regardless. It would be extremely difficult to run Xbone software on PC for the same reasons I already mentioned and why Xbox original emulation is so difficult. The hypervisor would need to be reverse-engineered

As for the PS4, AFAIK those are just encrypted ELF binaries so all that would have to be done is someone would need to reimplement the PS4s security coprocessor as its own library and just rip the PS4s libs that their games use


 No.937376

>>937268 (OP)

Emulating functionality is the easy part, the hard part is emulating all the edge cases hardware documentation doesn't tell you about.


 No.937378>>937408

>>937268 (OP)

That's how the PSP, Vita, and 3DS emus work. No need to emulate hardware when you have an Operating System with libraries.

Old games were running assembly and somethomes low-level C on some foreign RISC architecture, like some bootdisk. New games aren't.


 No.937383>>937660

>>937268 (OP)

https://www.youtube.com/watch?v=-AoHGJ1g9aM

This talk explains all the main differences between the current generation consoles and the standard PC architecture wise.

The main thing they found out is that the CPU has no support for legacy instructions and timers.


 No.937408>>937693

>>937378

You have no idea what you're talking about. Modern game console GPUs do use a fully programmable shader model, this is true, but console CPUs still need emulation and GPU shaders still need some level of recompilation. this isn't what OP is asking about at all


 No.937497>>937507 >>937519

File (hide): a2bddf588269827⋯.jpg (72.11 KB, 470x572, 235:286, phillipsfig1.jpg) (h) (u)

What about the opposite approach, recompiling console games as native apps? A couple links on static recompilation:

A professional effort with the TRS-80, along with a somewhat more conventional port from SMD to GBA:

https://web.archive.org/web/20060314214526/http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=68

An amateur effort with the NES:

https://andrewkelley.me/post/jamulator.html

In spite of the above being specifically about static recompilation, this basic ethos could certainly be applied to something which included certain amounts of dynarec and interpretation, or simply to a conventional emulator that intentionally included an extensive scripting/plug-in architecture for the purpose of per-game hacks.


 No.937507

>>937497

This actually looks like a neat concept


 No.937519

>>937497

If you had all the assembly instructions for the proccessor you could do something like this project https://github.com/trailofbits/mcsema >>934657

>x86 and x86_64 -> llvm intermediate

>McSema supports lifting both Linux (ELF) and Windows (PE) executables, and understands most x86 and amd64 instructions, including integer, X87, MMX, SSE and AVX operations. AARCH64 (ARMv8) instruction support is in active development.

>McSema enables analysts to find and retroactively harden binary programs against security bugs, independently validate vendor source code, and generate application tests with high code coverage. McSema isn’t just for static analysis. The lifted LLVM bitcode can also be fuzzed with libFuzzer, an LLVM-based instrumented fuzzer that would otherwise require the target source code. The lifted bitcode can even be compiled back into a runnable program! This is a procedure known as static binary rewriting, binary translation, or binary recompilation.

You could take the ISO's and turn their executable's into LLVM bytecode and compile that for *insert architecutre like x86 or RISC-V here*


 No.937524

>>937370

Cxbx Reloaded can play Jet Set Radio Future mostly fine now.


 No.937577

>>937282

>the only difference is you can't run your own programs on these machines

The switch can be easily hacked.


 No.937660

>>937383

>>937374

>all that would have to be done is someone would need to reimplement the PS4s security coprocessor as its own library and just rip the PS4s libs that their games use

I would think the same, plus redirecting / reacting properly to syscalls, their roadmap looks a little more complicated though:

https://github.com/AlexAltea/orbital/wiki/Roadmap

Im seriously considering buying a PS4 to get into this project, it looks so interesting.

>>937383

Thank you for the link. I also found three blog entries with some interesting details about the kernel, but it's not fully related, it's mainly about exploiting the hardware.

https://cturt.github.io/ps4.html


 No.937693>>937939

>>937408

>GPU shaders need some level of recompilation.

Not if the hardware target doesn't change. I wouldn't be surprised if the shaders in console were stored compiled.


 No.937939

>>937693

>I wouldn't be surprised if the shaders in console were stored compiled.

They are. But some level of translation is still required. Even if the shaders are the same, you still need to build a shader cache for the host drivers to read them




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
19 replies | 1 images | Page ???
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / 3rdpol / bcb / cutebois / had / lewd / shota / ss / tacos ][ watchlist ]