DuoS DSEMU

[Roor]

Originally Posted by Exophase

As you probably already know, iOS and Android don't have this problem. I don't know about Windows RT, but with this http://www.neowin.net/news/windows-r...un-signed-code you can probably run a recompiler. Surely their native apps will need it for things like the web browser's Javascript engine. If it's not possible now I'm sure MS will change this in the future.

Windows Phone 8 has a very small market share and I don't think this is going to change that much. Given that I don't think it's accurate to claim that most modern VMs running on phones don't allow you to execute code from memory.

That's why I wrote "with vanila kernel".

IOS has this problem (when not jailbroken, also Apple expressely forbids dynamically generated code).

Android allows you to run data as code (see DexMaker, but only allow Dalvik code), then for native, there's LOTS of issues when writing native code, because the huge variety of CPUs (ARM+X86+MIPS+ small/big ARM code variants).

WinRT & WP8 on the other hand just prohibit it; even if jailbroken so far; although one of the nice things in WinRT is that C++/DirectX code run native

I'm writing this after already having writen more than one recompiler and other stuff for each of those four OS/platforms (WinRT and WP8 are not the same, although there are similarities).

So again, most VM running on phones don't allow you to execute code from data memory; or write data into code memory, given the case... be it as by design, or then because legal reasons.

Anyway... VTM8 has nothing to do with DynaRec so far :P

__________________
Duos DSEMU official blog at http://ds-duos.blogspot.com

AdriPSX PSEMU official blog at http://adripsx.blogspot.com

[Exophase]

Originally Posted by Roor

That's why I wrote "with vanila kernel".

IOS has this problem (when not jailbroken, also Apple expressely forbids dynamically generated code).

Jailbreaking your phone doesn't change the kernel. It's an elevated privilege exploit. But if you're talking about running on un-jailbroken phones you have a more fundamental problem, because there's no way Apple is going to allow translations of someone else's software in their store. They probably wouldn't allow the program that makes the translations either.

Nonetheless, the current iOS version does allow mprotect to set PROC_EXEC (afaik not alongside PROC_WRITE however). I'm not sure if you can add this entitlement to signable code.

Originally Posted by Roor

Android allows you to run data as code (see DexMaker, but only allow Dalvik code), then for native, there's LOTS of issues when writing native code, because the huge variety of CPUs (ARM+X86+MIPS+ small/big ARM code variants).

There's no huge variety of CPUs. There are exactly two worth supporting: ARMv7a and x86. The latter is a bit of a stretch. Almost no one uses MIPS devices. Pre ARMv7 devices are too weak to care about. NEON support can be detected at runtime, but IMO it's barely worth even supporting anything w/o NEON because that's only Tegra 2 which doesn't have that many devices out in the wild.

x86 + ARM is really no different from wanting to support WinRT and Windows 8 like you do.

Originally Posted by Roor

WinRT & WP8 on the other hand just prohibit it; even if jailbroken so far; although one of the nice things in WinRT is that C++/DirectX code run native

Yes, but as of now few are using it.

Originally Posted by Roor

I'm writing this after already having writen more than one recompiler and other stuff for each of those four OS/platforms (WinRT and WP8 are not the same, although there are similarities).

What does the number of recompilers you've written have to do with it..?

For what it's worth, you're not the only person doing static recompilation of old PC programs. M-HT released a few game convertors for GP2X and various other handhelds. More recently there's this:

http://blog.winulator.com/

The distinction is that these aren't fully automated approaches and therefore specific games need some specific tuning. This is about what you'd expect. You may get several games naively, I don't know, but I'm pretty confident there's some you won't without special fixes. But then again I don't know if this was even your intention.

Originally Posted by Roor

So again, most VM running on phones don't allow you to execute code from data memory; or write data into code memory, given the case... be it as by design, or then because legal reasons.

I don't know why you're repeating this.. You can do it on jailbroken iOS, you can do it on Android, and non-jailbroken iOS is already irrelevant to you.

Most VM running phones are Android. Extend it to "phones that you'll be able to run your app on at all" and most will allow dynarecs, not prohibit it.

Originally Posted by Roor

Anyway... VTM8 has nothing to do with DynaRec so far :P

Right.

Just the same, here's my question, and it's the same thing I've asked everyone who has done or wanted to do static recompilers over the years (and I've met many) - what performance advantages do you have over dynarec? I get that that's not the reason you're doing it, but you seem to imply in an earlier post that you have a huge performance advantage and I'd like to know why.

[Roor]

I didn't want to go for a long explanation, but anyway.

As I mentioned before, it is similar to static recompilation, but it's not.

Performance increase happens mainly because VTM8 produces C code, that then can be compiled (and modified again, if someone wants to) on the original SDK. Lots of unnecesary stuff like silly loops, addressing, and LOTS of unnecesary access to memory doesn't happen at all... etc... etc... plus "usually" modern C compilers are a lot "smarter" than a "normal" dynamic recompiler by far...
The rest of the "hardware" is "emulated" in a similar way to how an emulator works... but again, it is "inlined" into the code... which is a HUGE change.
VTM8 detects all what we may call "immediate" code, so lots of unnecesary "low level" operations do not even happen (stuff like loading the first 16bits of a register... then shifting them... then adding the second 16bits... and then moving them into another register... that becomes something so simple as "UInt32 A=0x12345678;".
That's the "basic" explanation.

If it works, yes, it works.
If it has flaws, yes it does... automodified code in some games are a nightmare, so I had to add an "interpreter" to handle those tiny portions.

Jailbroken, or not, allowing recompilers or not, etc... was never an issue; but an answer to someone who asked if I was using something like that.

I mentioned I made several DynaRecs already, because I did, and I wanted to make you notice that I knew "a bit" about what I was writing about.

Regarding Winulator, I'm not familiar with it (I do not currently own Android devices myself, except the ones they sent me for Q&A from time to time).
It looks great, although it makes me remember a lot to QEMU and Bosch.

VTM8 is not an emulator per se, nor a static recompiler; but just a "procedure" that I allows to decompile and recompile code between different platforms. (I started with two for the time being).

I hope this satisfy your curiosity, if that was it.
Anyway... I don't think I'll add anything else to the matter.

Best regards,

Roor

__________________
Duos DSEMU official blog at http://ds-duos.blogspot.com

AdriPSX PSEMU official blog at http://adripsx.blogspot.com

[Bill_gates]

Originally Posted by Roor

I don't know if it would be fine to open a new thread, so I just post it here.
(please feel free to move this, if it is considered off-topic).

I'm looking for testers for my VTM8 project.
Basically, it is a "technology" that generates "native code" based on the original game binaries... It's similar to what we call Static Recompilation.
"Native code" basically means that there's no realtime CPU emulation, so CPU requirements are EXTREMELLY low.

So far, I implemented this new technique targeting all the new Windows 8 platforms (Windows Phone 8, Windows RT and Windows Store Apps), and it is working very nicely. Other platforms might come later.

VTM8 is not an emulator, but a complex procedure for generating brand-new native apps based on the binary-translation of a "source" game.
It is the by-product of extensive reasearch I made for producing a better DuoS emulator, for the last months.

Any person interested who actually owns a Windows 8 device (even an slow netbook running Windows 8 will do... although trying it on a Windows 8 Tablets or Windows Phone 8 would be very much helpful), please send me an email to vtm8@torum.com.ar

I have access to a windows 8 computer s id be willing to test
shoot me a PM

__________________
OS: WinXP Professional Service Pack 3
CPU: Intel pentium 4 3.0GHz
Video: Nvidia Geforce 8400GS
Sound: ASUS Xonar DS 7.1 Channels 24-bit 192KHz PCI Interface Audio Card
Memory: 512 MB
HD: [C:] 140.36/449.09 GB
Connection: Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller

[runawayprisoner]

Basically VTM8 is a "translator" that rewrites the "source" binary of a game into something that the intended platform understands in native code, right?

I had thought of a similar project as well... for JPSX (since JPSX is employing a similar technique with BCEL anyway), but the problem is always with self-modifying codes. You never know to what extent they modify themselves... and even to write an interpreter for them, you gotta know for sure that they'll stop modifying codes at some point. But... how can you be so sure they won't modify codes after that point?

I'd love to know how you get over that problem. Right now, it's truly nightmare trying to get over it.

[UpmostLion]

The emulator keeps crashing whenever I start a game. Can someone give me some advice.

Windows 7 laptop
Dual core intel CPU
1 GB RAM