Release PCSX ReARMed release thread


that worked, i linked the library and it says "error allocating memory" is there an argument to force it to allocate a certain amount of memory. free -m says i have 530 MB, do I need more than that?
It would help if you reported exact message, but I can guess you need to allocate more VRAM for DSS2, it's done using kernel argument, like "vram=8M". Don't know how it's done on touchbook, usually it's in u-boot or boot.scr .
 
BTW I've noticed you only track constants with register allocation, when they are evicted it's lost, which is a shame. Quite often I see large functions that load a pointer to scratchpad at their start, and access it throughout; but then it's register gets evicted and reloaded shortly, and those accesses can no longer be resolved at compile time.
I actually fixed that in yabause (see this patch).  It would be possible to do it for MIPS emulation too.  It wasn't a huge improvement, and only affected a small number of cases, which is why I haven't put a lot of effort into it.

Then there is a problem with those resolved accesses that the address is reloaded before each access needlessly, it could modify previous instead or use offset of ARM ldr instruction.
Yes, that's a problem.  I suppose it would be possible to keep track of what values are in which ARM registers and not reload values if they're already there.

I could try to change this but almost every change I do to register allocator or addressing stuff results in some real nasty regressions, that show up in 1/20 of games or so. I wish your recompiler was easier to work with *sigh*.
Early on I made some design decisions that in hindsight weren't the best way to do things, but I didn't know that at the time.  The constant propagation is one of those things.  When a constant is loaded into a MIPS register, you have to put the value into an ARM register and then write it out, so I only kept track of constants that went into ARM registers.  To really do it properly, you need to keep track of two separate states - one, when the virtual MIPS registers actually get updated with the proper values, and two, what values those registers are supposed to have, which are used to precalculate memory addresses even if the MIPS register is no longer assigned to an ARM register.


BTW, I think your assessment of the dyna_linker bug is correct.  I'm surprised that could happen, but only because new_recompile_block is so large that it will usually push everything else out of the L1 cache.  Apparently in rare cases it does not (although I've never seen it).  A sure fix would be to have dyna_linker flush the cache, although I think what you did will work.  Another possibility would be to not add the duplicate entries to jump_in[].
 
It would help if you reported exact message, but I can guess you need to allocate more VRAM for DSS2, it's done using kernel argument, like "vram=8M". Don't know how it's done on touchbook, usually it's in u-boot or boot.scr .
im using an arm natty narwhal ubuntu. My only guess is that mmap2 is trying to allocateba specific section of the memory thats already allocated by the operating system. I will post back if i can force it to allocate somewhere else.


http://pastebin.com/5th9xAXB
 
Last edited by a moderator:
BTW, I think your assessment of the dyna_linker bug is correct. I'm surprised that could happen, but only because new_recompile_block is so large that it will usually push everything else out of the L1 cache. Apparently in rare cases it does not (although I've never seen it). A sure fix would be to have dyna_linker flush the cache, although I think what you did will work. Another possibility would be to not add the duplicate entries to jump_in[].
It usually happened on certain games some time after loading a savestate and was extremely annoying. I had a sequence that would hit it with ~50% possiblility (load a game, wait ~3 seconds, load savestate and watch it crash) and was able to nail it down then.

im using an arm natty narwhal ubuntu. My only guess is that mmap2 is trying to allocateba specific section of the memory thats already allocated by the operating system. I will post back if i can force it to allocate somewhere else.


http://pastebin.com/5th9xAXB
That's not good, emulator relies on that 80000000 mapping and it can't be relocated. I've added MAP_FIXED to the latest git, maybe it will help but I doubt it.
 
It usually happened on certain games some time after loading a savestate and was extremely annoying. I had a sequence that would hit it with ~50% possiblility (load a game, wait ~3 seconds, load savestate and watch it crash) and was able to nail it down then.
Oh, so the pointers are coming from clean_blocks().  I'll bet that can happen in mupen64plus too...

That's not good, emulator relies on that 80000000 mapping and it can't be relocated. I've added MAP_FIXED to the latest git, maybe it will help but I doubt it.
There's a patch to relocate 0x80000000 in the 20110128 patchset.  It runs a few percent slower if you do this.  Notaz also has a mapping at 0x1f800000; I don't know if it's possible to relocate that one.
 
That's not good, emulator relies on that 80000000 mapping and it can't be relocated. I've added MAP_FIXED to the latest git, maybe it will help but I doubt it.
http://pastebin.com/ZVYjreK3


thats the change to the output. still doesnt work but thanks for the effort. i have a feeling this would be a moderate sized project to take on and unless you had a touchpad its likely not worth it.
 
Last edited by a moderator:
Hello notaz


very very thanks for your release


i like play with your emulator


you can fix glitch ergheiz and bloody roar 2


very thank for support pandora


openpandora forever
 
Hm, I think I found some new bug:


Xenogears crashes whenever you try to access the memory card (both for loading and saving)


Worked fine with R9.
 
Why pcsx4all plugin doesn't dislplay correctly 2D graphics? This plugin works better for some games, in fact it works a lot better with suikoden 2, I can play ii without any slowdowns.


But it does a weird thing: some images are displayed withe few horizontal pixel lines moved to the right witch make verical lines look like a saw. It's easy to notice in the text of many menu games or in the hud of racing games (tested in gran turismo and wipeout 2097), and is specially annoying in games with small 2D models where where characters (suikoden or breath of fire for example).


Any hopes to get the problem solved?
 
I must say, I've had a pretty-much unwaveringly awesome experience in Tomb Raider 1. I tip my hat to the folks behind PCSX ReARMed, amazing work!
 
Is anyone else getting some odd sound glitches in Castlevania SOTN? Not sure if it always did this, but the emulator also seems to slow down dramatically when you die before it goes to the Game Over screen...
 
Is anyone else getting some odd sound glitches in Castlevania SOTN? Not sure if it always did this, but the emulator also seems to slow down dramatically when you die before it goes to the Game Over screen...
I ran SOTN a few days ago to test out on r10, and it ran better for me than any other previous version(just about perfect:sound, frame rate, ect.). I didn't play it until death, but I believe the slow down is an in game effect that happens when you die(dramatic effect). I could be wrong, as it has been a long time since I played on a regular basis. Maybe someone else can confirm this.


Chris
 
Note the dual frame counters; I believe the one on the right is what speed the emulator is running at, whilst the one on the left is the speed the game is running at.
 
My version of SOTN was a PSP eboot, think I remember reading these sometimes have issues with this emulator, so I've tried another image and it seems to work perfectly so far!
 
Last edited by a moderator:
is it just me or does anyone else think that your inference should be used for every emulator?


It so easy to use its not even funny, but still gives you the power beneath
 
is it just me or does anyone else think that your inference should be used for every emulator?


It so easy to use its not even funny, but still gives you the power beneath
EVERYONE DOES!


Sadly, Notaz has stated it is a pain in the arse to program, and he would rather not do it personally for all the Pandora emu's. I would love it though, as it works really well. Hopefully N64 performance can be improved as much as PS1 at some point, and a menu like this one would be the icing on the cake! ;)


Chris
 
is it just me or does anyone else think that your inference should be used for every emulator?


It so easy to use its not even funny, but still gives you the power beneath
I think your inference is inferring interface. And yes every emulator should be like that! :D
 
Hey Notaz,


I ripped a bin/cue of the PAL release of Capcom's RPG Breath Of Fire III and find it doesn't load under r10 (gets stuck on the anti-piracy screen that all PAL discs display). For giggles i fired it up under r9 and it loads up fine and I could start the game, played for two or three mins without issue.


I can supply the aforementioned bin/cue for test purposes, if required.


Thanks,


gunrock
 
I ripped a bin/cue of the PAL release of Capcom's RPG Breath Of Fire III and find it doesn't load under r10 (gets stuck on the anti-piracy screen that all PAL discs display). For giggles i fired it up under r9 and it loads up fine and I could start the game, played for two or three mins without issue.

Game name and region is enough, thanks.
 
Last edited by a moderator:
I ripped a bin/cue of the PAL release of Capcom's RPG Breath Of Fire III and find it doesn't load under r10 (gets stuck on the anti-piracy screen that all PAL discs display). For giggles i fired it up under r9 and it loads up fine and I could start the game, played for two or three mins without issue.

Game name and region is enough, thanks.

Maybe it tries to access the memory card at start and suffers from the same bug as Xenogears? As mentioned, Xenogears crashes on R10 as soon as you access the memory card (load or save).


Works fine on R9.
 
Back
Top