Homebrew [Release] TemperPCE for 3DS

[drben]

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.

 

[arianadark]

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

 

[drben]

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.

 

[Onepunchbruh]

What console roms does it boot? let me know.

 

[arianadark]

tested the 3dsx version works great too for me

 

[drben]

tested the 3dsx version works great too for me

Hm, weird. Whats your 3ds setup? n3ds?

 

[nyder]

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

Downloaded a different bios, they are working correct now.

 

[arianadark]

Downloaded a different bios, they are working correct now.

good to hear and have fun

 

[nyder]

Love this emulator, as soon as it gets a 60 fps lock, it will be pretty much perfect on the N3DS

 

[bubble2k16]

http://drastic-ds.com/temper_src_2_12_2009.tar.gz

I believe this matches the last version released for GP2X and Wiz, which has the original renderer and its ARM implementation.

I'm tempted to try writing some assembly for the newer renderer just to see how much work it is, but I don't know if that's really going to happen.

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.

 

[angelhp]

Cd isos and bin/cue not found for me...
Can someone send bios for a private message ?
Thanks

 

[kane159]

Cd isos and bin/cue not found for me...
Can someone send bios for a private message ?
Thanks

sent

 

[bubble2k16]

I just tried the cia version and that one starts up.. but still no luck with the 3dsx version.

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.

Psychic Storm requires a Super System Card. Not booting up under any of the rom options. It's the extra 192k ram for TurboDuo games on the older systems.

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.

Finding on some Cd games that cut screens are causing the fps to spike up to 200ish (I have a N3DS) and then it crosses over into the game play, which makes the game play too fast.

Dragon Slayer is one example of this.

With some other games, the cutscenes are speeded up (100-200 fps) but when the game play comes on, it goes back to 60 fps, like Download 2 , Dungeon Explorer II, It Came From the Desert

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

 

[Exophase]

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.

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.

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

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.

 

[bubble2k16]

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.

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.

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.

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.

 

[GreatCrippler]

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?

 

[Exophase]

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.

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.

YYup, 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.

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.

 

[bubble2k16]

Can you try it with CPU_ARM_FAST_MODE?

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.

 

[bubble2k16]

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

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.

 

[DominoBright]

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!