• DCEmu Homebrew Emulation & Theme Park News

    The DCEmu the Homebrew Gaming and Theme Park Network is your best site to find Hacking, Emulation, Homebrew and for the first time Theme Park News and also Beers Wines and Spirit Reviews and Finally Marvel Cinematic Univers News. If you would like us to do reviews or wish to advertise/write/post articles in any way at DCEmu then use our Contact Page for more information. DCEMU Gaming is mainly about video games -
  • burrito

    by Published on August 27th, 2007 23:03

    mrdude has released a patch for the Pandora memory stick:
    Thanks to all those involved in the pandora files - you guys know who you are!

    The pandora files are great but they have a slight bug in the restore.elf file in the kd folder, as they make a nand dump nicely but forget to call it a name so it can be restored without manually renaming the dump.

    This patcher patches the restore.elf file in the kd folder - so that restoring nand files can be done without having to rename the dump.


    Either copy the Restore.elf Patcher.exe to kd and exectute it from the pc, or copy your restore.elf file to the same folder as Restore.elf Patcher.exe and execute. This will produce a 'fixed' elf file which you should replace in the kd folder.

    Now you will be able to restore your nand dumps without messing around - or the need of a computer. This file also creates a backup so if you prefer the original file - you will have a backup.

    NOTE: Remember to remove the battery & reboot the psp after you patch the file.
    Download and Give Feedback Via Comments ...
    by Published on August 27th, 2007 20:53

    Mrdude has released a GUI (graphical user interface) for Pandora's battery. This puts all of the needed files on your memory stick, and does the required formatting automatically.
    This still requires a homebrew-capable psp so that the normal battery can be turned into a Pandora battery.



    digg this

    by Published on July 20th, 2007 15:06

    via noobz

    With many thanks to GucciPAPA for sending us his Korean Lumines UMD, and to everyone else who offered to send theirs (including NeofaN, KkalKkal, Jabum, www.yourpsp.in ), we're proud to present an updated version of the v3.50 Lumines HEN and downgrader.

    The only change in this version is support for the Korean version of Lumines (ULKS46005). This now means that the downgrader should work on all unpatched versions of Lumines, on all regions of PSP, and all current PSP hardware, on firmware v3.50. If you have a lower firmware, you can upgrade to v3.50. If you have v3.51, then there is no way to downgrade at this time.

    For various further information about the downgrader, please read our other articles:

    Original downgrader release post
    Downgrader FAQs
    More downgrader information
    Information about patched Lumines versions
    Download Universal 3.50 Hen/Downgrader and Give Feedback Via Comments ...
    by Published on July 15th, 2007 23:20

    via pspgen.com

    Jas0nuk and lan.st admin, have just told us of the construction of a new 3.51 Custom Firmware.

    A team of around 10 coders, who want to remain anonymous for the moment, have started, as for the 3.51 M33, to reverse the DA firmwares, to create their own CF 3.51.

    Unlike the 3.51 M33, they do not wish simply to make a “3.51 OE”, as the 3.51 M33, but they wish to improve it, to make a version of a quality equivalent or higher than the Firmwares of Dark_AleX.

    Currently under development, a date of release is not in talk.

    Sounds great! ...
    by Published on July 15th, 2007 20:29

    Team M33 the releases of yesterdays new custom firmware have posted a quick update to their 3.51 custom firmware series.

    The Update fixes problems with Wifi not working on some homebrew games and apps.

    This update fixes a secondary effect that 3.51 wlan.prx caused in 1.50 wlan.prx,
    which made wlan homebrew not to work.

    Ths issue was caused by sony code of 3.51 wlan.prx, and not by M33 code.
    It doesn't happen replacing 3.51 wlan.prx with 3.40 one.

    - M33 Team

    Download and Give Feedback Via Comments

    Full install details and files Here ...
    by Published on July 14th, 2007 16:15

    via 0okm's Blog
    it use TA-085 PCB
    it has 64MB main memory
    (PSP-1000 main memory is 32MB)
    it can use USB to charge battery
    1200mAh battery can play about 3-6hours
    (same as PSP-1000, but PSP-1000 use 1800mAh battery)
    can't use PSP-1000 remote in PSP-2000
    TV output
    WLAN switch on top
    I was hoping that the new psp's battery would last longer.. ...
    by Published on June 26th, 2007 18:49

    via eXophase

    Users over at the IGN Boards are reporting that retail chain Gamestop is currently offering a free Syphon Filter: Logan's Shadow demo UMD. Not all stores appear to be offering the demo at this time, so its best to give them a call before heading out.

    Alternatively, you can request a copy of the demo from Sony at the official website. It's puzzling as to why Sony always limits new demos to UMD format, rather than offering a downloadable version. Ah well.

    Free Syphon Filter: Logan's Shadow demo UMDs [IGN Boards via PSPFanboy] ...
    by Published on June 20th, 2007 16:41

    I was at FYE and saw that they have a US$30 mail-in-rebate on the Core PSP.
    You need to purchase the psp before July 4, 2007. The rebate needs to be postmarked before August 4, 2007.

    This only works in stores, and not online. ...
    by Published on June 15th, 2007 19:15

    I was reading the comments from StrmnNrmn's latest blog update (June 14), and saw that StrmnNrmn answered many questions about Daedalus.

    Quote Originally Posted by michael
    Do you know whether it's actually self-modifying (as in, selectivelyish), reading a new routine from ROM (as in a loop from $b0000000), or a PI DMA?
    How are you handling PI DMA at the moment when it comes to code fragments?
    It took a short while to figure out exactly how it was modifying the code. I was worried that it was modifying the code via the cpu (i.e. manually updating instructions) but it turned out to be a DMA transfer. I'll post again with a bit more details about how I'm handling this.

    Quote Originally Posted by Legooolas
    I have been looking at ways to verify dynarec execution against an emulator, for similar reasons (but I'm just starting out in mine), so this is very helpful!

    Have you considered running both the emulator and dynarec in a semi-lockstep mode? I am going to try this when I get far enough into getting my dynarec working, as I'm not too worried about performance (yet... it's more of a learning experience and for some researchy ideas I have) and this should avoid the need to have a temporary log and the disk access. Of course it will be a lot slower, due to having to run two complete emulations at once, but this may prove quicker than going via disk?
    Glad you found the post useful

    I did consider the lockstep method (I believe Zilmar was using this on pj64) but I think the aproach I use in Daedalus is much simpler to get working. The lockstep approach would cause a few issues for the psp as you'd need to have enough RAM for two copies of the emulated RAM etc.

    It probably would be quicker than going via disk though, and less hassle to get everything set up.

    Quote Originally Posted by exophase
    Self-modifying code is perhaps the most annoying thing to deal with in a dynarec (that is, if you do in fact have to worry about it beyond cache invalidation). A good number of GBA games are very unfriendly in this regard. Actually, if it isn't checked for in general then a large number of games will fail outright.

    Of course, to detect it for the general case you have to add code to either check for it or change state somewhere after every write to RAM. In your case, since this happens relatively infrequently, you can probably manage to special case it only for certain writes in certain games.

    If you look at Project64's INI file you can see that there are several self-modifying code handling models (many of which probably don't really apply to PSP as it doesn't have an MMU). This alone indicates that it's a real problem for a number of N64 games, although perhaps not the most popular ones.

    One thing I do recommend, if you're not already doing this, is to have separate translation caches for code that is in RAM and ROM (and not directly linking fragments between the two). That way you don't need to flush all of the generated code upon an icache invalidation or other detected modification, rather just the code in RAM. You can also go a step further and split things into dynamic and static regions to track modifications and try to minimize flushing overhead. This is only a concern if the game modifies code heavily - if any N64 games are like some GBA games then there will be ones that modify code many times a frame.

    I talked about this issue in my blog, if you're interested: http://gpsp-dev.blogspot.com/
    Hiya. Most n64 games seem to be pretty well behaved (they generally invalidate caches where required) which is why I've not spotted too many problems in the past.

    They don't generally seem to modify code very frequently either - usually just on specific events (e.g. transfer from menus to game etc) rather than on a frame-by-frame basis.

    Separate caches is a good idea though, I'll investigate that this weekend.

    Quote Originally Posted by Jeff
    In a word: whoa!

    Great job StrmnNrmn. Here's a question for ya: can the SSB rom be 'patched' to work correctly? Maybe not the file itself, but during the loading you have game-specific patches that Daedalus adds on the fly?

    Also, on an unrelated note:

    Is it possible to implement some kind of down-sampling of the N64's textures in order to save ram? The PSP's screen is tiny (large by handheld standards sure, but still smaller than a TV) and I am wondering if people would notice or care if the textures were reduced.

    Keep up the great work man. I gotta say, you're regular posts are motivating. I have a wierd urge to try an Atari Jaquar PSP emulator with JIT dynarec! (okay... it passed)
    In the past I've gone to the length of scanning the rom for recognisable library functions and patching them (mostly just to help debug what's going on with the rom, but also for optimising a few things like memcpy() etc). There's no reason why I couldn't use the ...
    by Published on June 12th, 2007 01:08

    via http://strmnnrmn.blogspot.com/

    Tracking down the SSB Dynarec Bug

    Yesterday I said I'd provide some more details about the Super Smash Bros. dynarec fix. The actual fix is fairly straightforward, but I thought the process of tracking down the issue was quite interesting and worthy of a couple of blog posts.

    When I first started looking at SSB I noted that although the game ran fine without dynarec, it would always hang when trying to enter the main entry with dynarec enabled.

    I've been programming professionally for around 6 years now and I can safely say that debugging dynarec bugs is one of the hardest categories of problems I've ever had to work on. For a start, because the code is generated on the fly, you don't have the luxury of source level debugging, and without spending time reverse engineering the original rom image, you don't even know what the generated dynarec code is meant to be doing. It's very much like working blindfolded.

    And it gets even worse. I've fixed dynarec problems in the past which were the result of generating incorrect code for a fragment over 500 million instructions into emulation. This would be bad enough, but it can be many thousands of instructions later before this causes emulation finally diverges from the correct path. Just identifying the exact point at which the emulation starts to diverge from the correct sequence of instructions can be like finding a needle in particularly large haystack. While blindfolded

    Over the years of trying to debug problems like these I've built up a set of tools and learned a few tricks along the way which you might find quite interesting. Although I'm going to talk about them in the context of tracking down this dynarec issue, I've found some of the techniques useful in solving other problems so you might find other ways of applying them too.

    One of the first things I do when trying to identify a dynarec issue with Daedalus is to see if the problem is reproducible on the PC build of the emulator. Although it is possible to use GDB with PSPLink, I've never got this up and running and I'm much more comfortable debugging with Visual Studio. Also, working with the PC build is usually much faster than working with the PSP build (debug builds run around 10x faster on the PC, and build times are much quicker.)

    Not all dynarec issues can be debugged in this way - the PSP and PC builds have different code generation back-ends (i.e. MIPS and x86 code generation respectively) so bugs in the MIPS code generation won't usually be reproducible in the PC build. The dynarec system in Daedalus shares a common frontend (trace selection and recording) between the two platforms, which means that if I can reproduce the problem on both platforms, I can narrow down the likely location of the bug to this area.

    Fortunately this particular bug manifested itself in both the PC and the PSP builds, so I knew that if I fixed the bug on the PC build, it should fix the PSP build too. What I needed to find out next is what the emulator was doing differently when dynarec was enabled compared to when it was disabled.

    If dynarec is running without errors, then the sequence of executed instructions should exactly match that executed with dynarec disabled. If I could log details about all the instructions executed with dynarec disabled, and again with dynarec enabled, I should be able to compare the two logs to figure out the exact point at which dynarec is going out of sync. This all relies on the fact that the emulator is totally deterministic, i.e. that running the emulator twice in succession with the same settings should give exactly the same results.

    Unfortunately, for a variety of reasons my dynarec solution doesn't produce identical results to interpretation, the main reason being that for performance reasons I can only handle vertical blank and timer interrupts on the boundaries between fragments. For example, with dynarec disabled, the first vertical blank interrupt might occur exactly on the 625,000th instruction, but with dynarec enabled with might not occur until the 625,015th instruction. This means that the logs diverge at the instant the first VBL fires, and never regain synchronisation.

    When I was originally developing the new dynarec system I put a lot of effort into writing a fragment simulator, the idea being that rather than executing the native assembly code for a given trace, I could keep track of the instructions making up the trace and interpret these individually instead. Theoretically fragment simulation is identical to dynarec code execution, even down to the way I handle VBLs and timer interrupts, and it's been very useful at identifying bugs in the dynarec code generation. What's particularly useful about fragment simulation however is that I can enable a setting which
    Page 1 of 4 1234 LastLast