Author Topic: Help new_dynarec  (Read 12214 times)

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #15 on: December 17, 2014, 02:09:13 PM »
Goldeneye 007 makes heavy usage of TLB exception handling.

You can thank the developer of n64js for mentioning it in a blog post.
« Last Edit: December 17, 2014, 02:22:06 PM by retroben »

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #16 on: December 17, 2014, 04:50:10 PM »
I now have root on my x86 tablet and I am more than ready to test your build whenever you guys decide to post it.  ;D

Offline bsmiles32

  • byte
  • *
  • Posts: 15
    • View Profile
Re: Help new_dynarec
« Reply #17 on: December 17, 2014, 05:24:56 PM »
New WIP version with TLB working in the mailing list.

The method I used to get it working is fragile, and I welome ideas on how I can improve robustness of it.
(I play with the stack pointer value in order to jump to the tlb_exception handler, which disrupt the normal execution flow).

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #18 on: December 17, 2014, 05:44:13 PM »
Sorry,my brain falls out whenever manual building from source is involved.
The patch,what do you even patch for testing it?
You must have a personally shared apk copy that is inaccessable to plebs/scrubs like me. :(

Are you testing through advanced debugging or just running the certain games to see if they no longer crash with the changes you make?

Offline bsmiles32

  • byte
  • *
  • Posts: 15
    • View Profile
Re: Help new_dynarec
« Reply #19 on: December 18, 2014, 04:26:54 AM »
@retroben:

If you want to play with this work, it goes something like this (not verfied) :

* Clone the [1] git repo
* Checkout the refactor_memory branch
* Apply WIP4 patch on top of it
* Compile the core with NEW_DYNAREC=1
* Run mupen64plus --corelib ./_path_to_the_newly_compiled_libmupen64plus --emumode 2 ~/Whatever_Rom_to_test

I don't use the AE version, so no, no APK from me.

I am not aware of any "advanced" debugging features in the current codebase, so no I only run some games to test.

[1] https://github.com/bsmiles32/mupen64plus-core

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #20 on: December 18, 2014, 11:08:53 AM »
Since I have root now,maybe there is a way to get Linux running and WINE to run as well.
Turns out it in fact has 1.8Ghz CPU speed,which is more than my FireTV.

You will probably need to test games again once you get it implemented on Android.
I will just have to wait for you to get at the Android phase so I can help by testing other games while you are testing some. (that way I can help double your testing speed,or at least increase it)

You may already know this,but games that don't work on Intel Android x86 in all verions are Banjo-Tooie and DK64.
There's probably some other games,but both Zeldas,SM64,SSB,and even Banjo-Kazooie all run fine.

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: Help new_dynarec
« Reply #21 on: December 18, 2014, 01:31:19 PM »
Retroben I fixed banjo-tooie on x86, I also have a fix for dk64 but ari64 doesn't like it so I haven't push it upstream ;-) I will send you an apk for testing soon but first I want to finish things I am currently working on ;)

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #22 on: December 18, 2014, 02:54:49 PM »
Nice! Thanks Gillou. :)

I recently tried out Conker on x86 and it is really fast on your version with my tablet,and I fixed my touch annoyance of the controls being too small by scaling it to 155% size.

Why not just make the DK64 fix for downstream only?

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3496
  • Developer
    • View Profile
    • PaulsCode.Com
Re: Help new_dynarec
« Reply #23 on: December 18, 2014, 03:09:09 PM »
Why not just make the DK64 fix for downstream only?

I think we want to continue taking Ari64's opinion seriously on these questions, given his wealth of knowledge on the subject.  If he has qualms about how something is implemented, there is probably a pretty good chance it will cause problems in certain scenareos (and may be difficult to know why if it isn't noticed immediately).  IMO, it is better to be patient and work through the problems to ensure they have a solid implementation (thinking from a long-term perspective).
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #24 on: December 18, 2014, 06:00:00 PM »
Okay,makes sense.

Also,I call HAX! You posted at 999!!! ;D

Offline bsmiles32

  • byte
  • *
  • Posts: 15
    • View Profile
Re: Help new_dynarec
« Reply #25 on: December 19, 2014, 05:48:21 PM »
Updated the pull request to include the work on the x86 backend.

I also pushed separately the "fix" for Super Mario 64 in another pull request.

I'd like to start working fixing the ARM backend, but I'd like pointers on how to setup a suitable dev environemnt:
-arm {cross}compiler
-arm emulator (as I don't have an ARM device)
Otherwise, it will be mostly guess work + external testing :(

Any suggestions?
Thanks

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: Help new_dynarec
« Reply #26 on: December 20, 2014, 12:03:32 AM »
Still waiting as patiently as I can.

While waiting,I got melee running in Dolphin on my tablet (even with the OpenGL backend),but since the recompiler is ARM only,it is pathetically slow on my x86 device with houdini.
Why is there still the lack of an x86 build of Dolphin Emu for Android?
I previously tried Reicast,but could only get the BIOS to run because SA2 crashes it.

So now,here I am,waiting... (Dexter's dad:and waiting,and waiting,and waiting...and waiting.)  :D

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: Help new_dynarec
« Reply #27 on: December 20, 2014, 05:36:14 AM »
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline bsmiles32

  • byte
  • *
  • Posts: 15
    • View Profile
Re: Help new_dynarec
« Reply #28 on: December 20, 2014, 08:00:58 AM »
Quote
Which commit should I build from?  Is it this?
https://github.com/bsmiles32/mupen64plus-core/commit/b1160dba638e35d612d622659e07b0d3f0fda098

Yes :)

Additionally, if you encounter an assert error with Super Mario 64 like I did, you can also import this commit :
https://github.com/bsmiles32/mupen64plus-core/commit/3df9973e289f7783f464599f414c717c8bf26360

Thanks for your feedback :)

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: Help new_dynarec
« Reply #29 on: December 22, 2014, 04:39:11 AM »
Ok I made a reply on google groups like 2 days ago and it's still not posted so I guess I will avoid google groups like FOREVER!!!!!!!!!!!!!!  >:(

Anyway I was mainly saying that I had time to work on the memory refactor stuff and I think that the best way to do this is to port everything to assembly in order to avoid such patches:

Code: [Select]
emit_writeword(ESP, (int)&g_mem_saved_stack_pointer);
Code: [Select]
static inline void goto_tlb_exception(uint32_t cause, uint32_t address)
{
#if NEW_DYNAREC == NEW_DYNAREC_X86
        asm volatile (
                "mov g_mem_saved_stack_pointer, %%esp\n"
                "sub $4, %%esp\n"
                "jmp tlb_exception\n"
                : /* no output */
                : "a"(cause), "b"(address)
                : /* no clobber */);
#else
#error TODO: goto tlb_exception not implemented
#endif
}

Here's my work so far:
http://pastebin.com/PZq31KSE

This is mainly a proof of concept, it's not entirely tested and it's definitely not well optimized.
Also as I'm working on windows this is intel format assembly so this need to be converted to AT&T in order to be merged in the current linkage_x86.s sorry about that.  :(