[Release] TemperPCE for 3DS

Discussion in '3DS - Homebrew Development and Emulators' started by bubble2k16, Jun 18, 2017.

  1. drben

    drben Newbie

    Newcomer
    1
    Aug 9, 2016
    Gambia, The
    I din't have the folder syscards in there before but I just tried it with that folder in there but it still wont work.
     
  2. arianadark

    arianadark GBAtemp Advanced Fan

    Member
    6
    Nov 20, 2016
    United States
    inside the syscard folder u need the bios named exactly like this
    1. If you have the CD ROM BIOS, place them in the /3ds/temperpce_3ds/syscards folder.
    2. They must be named:
      • syscard1.pce
      • syscard2.pce ,
      • syscard3.pce ,
      • games_express.pce
     
  3. drben

    drben Newbie

    Newcomer
    1
    Aug 9, 2016
    Gambia, The
    But wouldn't that only be necessary if I want to play CD games? for the normal .pce files the bios shouldn't be necessary.
     
  4. Haider Raza

    Haider Raza Alhumdulillah

    Member
    4
    GBAtemp Patron
    Haider Raza is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    Jan 30, 2016
    Pakistan
    What console roms does it boot? let me know.
     
  5. arianadark

    arianadark GBAtemp Advanced Fan

    Member
    6
    Nov 20, 2016
    United States
    tested the 3dsx version works great too for me
     
  6. drben

    drben Newbie

    Newcomer
    1
    Aug 9, 2016
    Gambia, The
    Hm, weird. Whats your 3ds setup? n3ds?
     
  7. nyder

    nyder GBAtemp Fan

    Member
    6
    Mar 6, 2014
    United States
    Downloaded a different bios, they are working correct now.
     
    Last edited by nyder, Jun 20, 2017
  8. arianadark

    arianadark GBAtemp Advanced Fan

    Member
    6
    Nov 20, 2016
    United States
    good to hear and have fun
     
  9. nyder

    nyder GBAtemp Fan

    Member
    6
    Mar 6, 2014
    United States
    Love this emulator, as soon as it gets a 60 fps lock, it will be pretty much perfect on the N3DS
     
  10. bubble2k16
    OP

    bubble2k16 GBAtemp Fan

    Member
    10
    Jul 25, 2016
    Senegal
    Great! Thanks!

    I tried to use the cpu_arm_asm.s code in gameblabla's version on Github, and you'd be surprised to hear that it actually runs worse than cpu.c (compiled with O3 optimisation)

    Here are the timings running on Salamander's title screen (for 60 frames - 1000ms)

    cpu.c
    CPU Emulation: avg 710ms
    GPU Rendering: avg 55ms

    cpu_arm_asm.s (CPU_ARM_FAST_MODE defined)
    CPU Emulation: avg 920ms
    GPU Rendering: avg 55ms

    *CPU emulation includes all the read/writes to and from TG-16's memory and hardware registers (but does not include any rendering)

    That was my experience using the cpu_arm_asm.s (at least based on gameblabla's version) that I told you before. I've tried to integrate yours into this port, but apparently I still need some work the sync the cpu_struct / irq_struct / memory_struct layout with the asm version. Haven't got much time to fix that part.

    Given these timings, I don't even want to go to the software rendering part. Blitting pixels on the 3DS hardware is helluva slow. :(

    EDIT: I should add that idle loop patching was disabled in both cases.
     
    Last edited by bubble2k16, Jun 21, 2017
  11. angelhp

    angelhp GBAtemp Fan

    Member
    6
    Nov 30, 2014
    United States
    Cd isos and bin/cue not found for me...
    Can someone send bios for a private message ?
    Thanks
     
  12. kane159

    kane159 GBAtemp Regular

    Member
    5
    May 28, 2013
    Taiwan
    sent
     
    angelhp likes this.
  13. bubble2k16
    OP

    bubble2k16 GBAtemp Fan

    Member
    10
    Jul 25, 2016
    Senegal
    Strange... not too sure what's wrong - sounds like a memory issue, I just don't know where in the code it is having this problem. I haven't gone on to B9S + Luma 8.0 yet, so I don't really know how to fix this problem either. :(

    You need get and place the syscard3.pce into your /3ds/temper_pce/syscards folder. Then, select "CD-ROM v3" in the BIOS option. It seems to work for me.

    Thanks for pointing out. Will try on my New 3DS when I get the time! :)
     
  14. Exophase

    Exophase Member

    Newcomer
    3
    Jan 22, 2008
    United States
    I looked at the code again and unless I'm missing something you have DEBUGGER_ON defined in platform_defines.h. You should definitely take that out and test both sides again because the debugger will slow down both CPU interpreters a lot. The slowdown is even worse in the ARM ASM version because it has a pre-check which checks for countdowns (which won't be the case by default) and it has to save and restore more state to go in and out of the debug function. So that'd explain why both measurements look really bad and the ARM one looks even worse.

    I'd also pass this on to gameblabla in case it's happening in the GCW Zero port too.

    Can you explain further what this means? The part that blits is in software and it shouldn't be that slow with a sufficiently optimized renderer. From what I've read, direct framebuffer updates on 3DS are slow. I don't know anything else about this, like if it's because of post-processing (I hear the layout is rotated and maybe something is rotating it back? Which is murder on a CPU that doesn't have L2 cache to store a framebuffer) or maybe the MMU isn't configured to efficiently write to this region of memory, like with write buffering and coalescing turned on.

    But you should be able to render to a texture and use the GPU to render it instead of drawing directly to the framebuffer.

    For comparison, in the worst case you're re-caching everything visible on the screen when the entire palette changes. In 256x240 resolution that can be up to 33x31 unique tiles for the background and since you're not doing anything to limit the number of sprites shown per scanline it can be up to 64 unique 32x64 sprites. That'd be a total of 196544 pixels, although in practice the VRAM can only store about 62KB of tile and pattern data, so the real limit is around 126976 pixels unless the same tiles/patterns are being used with different palettes. Still, that's a lot higher than the 61440 pixels you'd need to update if you uploaded a software rendered 256x240 framebuffer. And it'd come in the form of one large texture upload instead of many small ones.

    And when you have to cache everything you end up doing a lot of the work you'd do in a software renderer, like palette lookups.

    This may not show up when benchmarking something relatively static like a title screen but it can turn into a real sudden grind, like if the game fades out the screen.
     
    Last edited by Exophase, Jun 21, 2017
  15. bubble2k16
    OP

    bubble2k16 GBAtemp Fan

    Member
    10
    Jul 25, 2016
    Senegal
    Yes you are right, it seems like DEBUGGER_ON is defined. I did a quick benchmark:

    cpu_arm_asm.s (CPU_ARM_COMPATIBILITY_MODE defined, DEBUGGER_ON turned off)
    CPU Emulation: avg 450ms
    GPU Rendering: avg 55ms

    It's a big improvement in performance, but some games (seems like especially the CD-ROM ones) seem to lock up the whole emulator. Digital Champ also doesn't boot. Any ideas?

    And the music generated is totally off. Probably due to the queueing of the PSG writes. Will need to look into that in detail.

    EDIT: here's the benchmark for the C emulator:
    cpu.c (DEBUGGER_ON turned off)
    CPU Emulation: avg 670ms
    GPU Rendering: avg 55ms
    A modest gain, but still a gain nonetheless.

    Yup, the rotation kills performance. Rendering to texture is what I do for the VirtuaNES port. I tried that in TemperPCE in the earlier days with the DEBUGGER_ON in place, obviously then, it didn't help much to bring the playable frame rates down to 60fps.

    I don't have any figures for the software rendering now, but will get to it as soon as I figure out what's happening with the CPU and sound when using the assembly version.
     
    Last edited by bubble2k16, Jun 22, 2017
  16. GreatCrippler

    GreatCrippler Greatness Fallen

    Member
    7
    Mar 27, 2010
    United States
    Grand Junction, Colorado
    I really enjoy a lot of the games on the TG16. That said, I have never had any trouble running them on my regular DS cart. Is there any advantage to this release over that?
     
  17. Exophase

    Exophase Member

    Newcomer
    3
    Jan 22, 2008
    United States
    Can you try it with CPU_ARM_FAST_MODE?

    I don't know what the issues are with PSG and CD but it's possible that a simple change in performance is revealing concurrency problems with these things happening on the other core.

    If the issue is only rotation it's possible to make video.c output rotated scanlines with a pretty small modification. The performance should only be slightly worse than the non-rotated version. This is assuming you're able to get a non-rotated framebuffer.
     
  18. bubble2k16
    OP

    bubble2k16 GBAtemp Fan

    Member
    10
    Jul 25, 2016
    Senegal
    Yup.

    cpu_arm_asm.s (CPU_ARM_FAST_MODE defined, DEBUGGER_ON turned off)
    CPU Emulation: avg 370ms
    GPU Rendering: avg 55ms

    EDIT:
    I replaced my hardware renderer with the unoptimised software renderer:
    CPU Emulation: avg 370ms
    SW Rendering: avg 395ms (using renderer in video.c)

    I haven't tried the optimised one yet.
     
    Last edited by bubble2k16, Jun 22, 2017
  19. bubble2k16
    OP

    bubble2k16 GBAtemp Fan

    Member
    10
    Jul 25, 2016
    Senegal
    Hmm... I think I might have found a bug in the cpu_arm_asm.s. Fortunately, it occurs early enough to detect and quickly fix:


    #ifdef CPU_ARM_FAST_MODE
    .globl ext_symbol(execute_instructions_fast)
    ext_symbol(execute_instructions_fast):
    #endif

    #ifdef CPU_ARM_COMPATIBILITY_MODE
    .globl ext_symbol(execute_instructions_compatible)
    ext_symbol(execute_instructions_compatible):
    #endif

    ldr r1, 0b @ r1 = cpu

    ldr r2, [r1, #0x0] @ r2 = cpu.global_cycles low
    ldr r3, [r1, #0x4] @ r3 = cpu.global_cycles high

    addadds r2, r2, r0 @ cpu.global_cycles += cycles
    adc r3, r3, #0


    The "add" is missing the "s". Without that the global_cycles mess up causing the threaded PSG to work incorrectly (at least for this port). Can't tell if it matters to you, but I figured it's good for you to know too.
     
    Last edited by bubble2k16, Jun 22, 2017
  20. Palom

    Palom GBAtemp Regular

    Member
    6
    Sep 21, 2009
    United States
    It's a bit of a bummer that ISO/OGG/CUE doesn't work (or at least it didn't for me when I converted a game, it works otherwise), and I can't play Monster Lair even for 30 seconds without a crash reported by Luma 8.0, but other than that, I'm happy with this! I wasn't expecting CD compatibility at all, much less other CD games I've played not crashing when I try to either switch games or exit the emulator, and said games actually play well! One release and it's already better than the RetroArch core. Thanks bubble, and thank you Exophase for making Temper and helping bubble with the next version. Looking forward to it!
     
    bubble2k16 likes this.
Quick Reply
Draft saved Draft deleted
Loading...