• 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 Theme Park News and also Beers Wines and Spirit Reviews and Finally Marvel Cinematic Universe 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 -

    If you are searching for a no deposit bonus, then casino-bonus.com/uk has an excellent list of UK casino sites with sorting functionality. For new online casinos. Visit New Casino and learn how to find the best options for UK players. Good luck! - Explore the possibilities with non UK casinos not on Gamstop at BestUK.Casino or read more about the best non UK sites at NewsBTC.
  • tsurumaru

    by Published on February 9th, 2007 01:19

    Yes Strmnnrmn lives.

    This ought to show people to have a little more patience.

    http://strmnnrmn.blogspot.com

    Behold! An update!

    Wow, it's been a long time since the last update. A really long time. How did that happen?

    I've always found it quite hard to find the time to update the blog. Usually when I have some free time in the evenings (that's free time spent doing things other than eating, socialising, and getting stuff ready for work), the choices I have are:

    * Do some new development on Daedalus
    * Play games/watch TV/relax
    * Reply to a few emails/comments, post a new entry here

    Unfortunately over the past half year or so the first two bullet points have won out. So, apologies for neglecting the 'outside world' for so long. On the plus side, the existance of the first bullet points means that I have lots of exciting new developments to talk about over the next few days

    I'm going to finish off this reintroduction with a broad overview of some of the stuff I've been working on. This is all stuff that will be present in R9, which I'd like to release this month.

    * Added support for RGBA 4444 and 5551 textures, saving a bunch of memory in the front end.
    * Tidied up all the texture conversion code, fixing a few bugs in the process
    * Fixed the width/height of FillRect calls in 1 and 2 cycle mode (fixed a few small graphical issues)
    * Fixed a blending bug (fixed a few small graphical issues)
    * Use 16-bit textures on the PSP to represent 16-bit N64 textures. Saves time converting, saves memory, and faster rendering
    * Added mirrored texture support (this fixes lots of small graphical glitches)
    * Fixed a LoadTile bug, allowing a couple of hacks to be removed (this also fixes various small graphical glitches)
    * Added some new blend modes for various roms
    * Fixed the Tri2 command for F3DLX microcodes
    * Fixed a bug in busy-wait detection (this wasn't working correctly with dynarec code, net result is a small speedup)
    * Fixed a few dynarec stability issues (relating to exceptions occuring mid-trace)
    * Added audio support
    * Added the ability to dump textures (developer builds only at the moment)
    * Fixed screenshots. Again.
    * Implemented cmp.s, cvt.s, cvt.w, mtc1, mfc1, bc1f, bc1t, j, cfc1, ctc1, daddu, trunc.w.s, bc1t, bc1f, bc1tl, bcifl, bnel, beql, blezl, bgtzl, bltzl, blezl in dynarec (this gives a decent speedup)
    * Avoid setting the branch delay flag and current PC in generated dynarec code unless absolutely necessary (this gives another small speedup)
    * Much better memory access handling in dynamically recompiled code (this gives a BIG speedup
    * Use a second code buffer for generated dynarec code, to avoid polluting the instruction cache (this gives another small speedup)
    * Further improve the memory access handling in generated dynarec code (another small speedup)
    * Fix register usage analysis for lwc1/swc1/mfc1/mtc1 which was preventing base registers used in these instructions from being cached (another small speedup)
    * Have compensation blocks restore nobbled registers, so on-trace code does't need to reload (another small speedup)


    There's quite a lot in that list, so I highlighted the two most significant points. In summary R9 will be much faster, with audio support. I'll write a bit more about these changes in particular over the next few days (promise!)

    -StrmnNrmn

    Now show the guy a little respect, don't hassle him with trivial things and let him get on with the coding! ...
    by Published on January 10th, 2007 14:02

    Hi all,

    Since many people seem to be unable to read the readme in Cintro Mod V 1.0.2 I thought I would post this as news to hopefully reduce the number of bricks occuring.

    If you use V 1.0.2 on FW 3.03OE you will brick your PSP! You won't be able to go into the recovery menu.

    Reason:

    "The 3.02OE-B vshmain.prx in module is different from 3.03OE-A's so the program hex edits values that arent ment to be edited as they are in different places.

    aka. brick."

    To counter this a new version for 3.02OE - B & 3.03OE- A & 3.03 OE - A2 has been released.

    This version should be safe but remember flashing your PSP always has a risk. ...
    by Published on January 3rd, 2007 18:29

    Dark AleX has posted that he hopes to commence work on 3.03OEA custom Firmware soon and will be finished within a day! (Provided there are no problems I guess)

    The following is taken from a post regarding psx2psp V 0.6

    "There is a problem with the application.

    The iso header offset currently MUST BE 0x50000, since one of the functions of popcorn that replaces a popsman function (to allow decrpted headers) will search the postheader at 0x50400, where are data needed by pops.prx.

    I've seen than the appplication does not always generate the data there, and this could cause the generated pbp not to work properly.
    In fact, this was one of the reasons of popstation to not allow big images.

    Anyways this will be fixed in popcorn.prx of 3.03 OE-A by searching the iso offset in the pbp header, but currently in 3.02OE-B, isos whose header are not at 0x50000 cannot be guaranteed to work.
    In fact they could work depending of the luck of the values of the data that are at offset 0x50400+.

    No need to change nothing in the app anyways, since i may start working in 3.03 OE tomorrow, and it should be ready next day."

    Looks like the next release will support psx compressed ISO's! (Thanks jak66)

    Link to source ...
    by Published on December 28th, 2006 16:52

    source code via Dark_aleX

    Well this may be of interest to some scene goers. Dark _Thug "coder" of the fake 2.80 downgrader for TA082 (released a couple of weeks back) hijacked a release thread in another forum saying that Dark Alex had stolen his code in his new TA082 downgrader release.

    Dark AleX, 0okm and others had already looked at Dark_Thugs release and found that it was in fact a copy of DAX's earlier downgrader with only minor changes that fortunately made it not execute on TA082, as it contained no changes to the ID data and therefore would have bricked TA082s!!!!

    Anyhow its clear Dark_Thug has some sort of vendetta against DAX and as such people should be aware of the official Dark_AleX sites in case something similar to the fake site Brickers occurs again.

    Dark_AleX delayed the release of the source due to these problems but here it is:

    Dark_AleX is currently looking at whether the 2.80 downgrader from 0okm and TA082 downgrade processes can be combined so as to give a TA082 2.80 downgrader but give the man time!

    be aware that there are some users through-out the homebrew scene out to brick psp's. We advise that you only go to www.dark-alex.org to view his projects, as there are other users that use his name to put out "bricker" programs. Thank you!

    download and give feedback via comment ...
    by Published on December 28th, 2006 16:38

    new easy downdater via csfreakno1

    Hi, all Files are included, with README.



    This is a easy downdater for ta082 psp's running on firmware 2.71. This program makes it easy to set up the downdater for quick use. Please read the Read me!

    Warning: Flashing always risks bricking your psp. Use with caution!

    download and give feedback via comment
    download via csfreakno1 ...
    by Published on December 20th, 2006 00:33

    Hot off the press on Bungie.net:

    Et 2am Brute?
    Posted by Frankie at 12/19/2006 3:01 PM PST

    Something’s going to happen. Something wonderful.

    Tomorrow morning, on December 20th at 2am PST (Pacific Standard Time) the US English version of our next “ViDoc” will go live. What’s a Vidoc, you ask? A Video-Documentary. What’s it about, you ask? It’s about Brutes in Halo 3, but before we say more, read the following caveats just so there’s no confusion:

    · There are no finished graphics in the documentary, and everything you see is a work in progress.

    · This will be available initially only on Xbox Live Marketplace.

    · The first version of the Vidoc, US English, will be live at 2am, PST.

    · The rest of the localized language versions will be parceled out afterwards, hopefully within 24 hours. Please be patient.

    · We will make another, non-marketplace version available relatively soon.

    · It runs for seven minutes.

    · Standard definition and high definition variants will be available.

    The documentary will run for almost exactly seven minutes (coincidence? UNLIKELY!) and contains a first peek at the bad guy you will grow to love and hate in Halo 3. Well, mostly hate, but you will love fighting him.

    You’ll see what amounts in a way to the first glimpse at Campaign content, but don’t get too excited. Everything you see here is a work in progress, and I’m afraid you won’t be seeing anything like finished graphics. This is just a chance to talk about the design philosophy and production behind what’s going to become a very important part of the next game. But don’t worry, I’ll answer lot more questions tomorrow. ...
    by Published on September 3rd, 2006 13:28

    Hi DCEMU crew,

    Its with a mixture of sadness and respect that I write this report to you. For the benefit of those that haven't been keeping an eye on Yoyofr and Laxer3a's forums for SnesTYL9x, for some time now both Yoyofr and Laxer3a have been saying that they have less and less time to spend on the emulator. In fact they have mentioned that at some stage they would have to stop updating it and it looks like that point might be soon.

    "Hi,

    We are thinking about doing a "final release".
    Yoyo does not have the net for a few weeks again... Need to wait a bit.

    See you.
    "

    http://yoyofr.proboards44.com/index....ead=1156247762

    Laxer3a has explained that they have pretty much come as far as they can in terms of the speed of the emulator.

    He does believe that if there was a major overhaul of the code to incorporate a dynamic recompiler/JIT then there would be the possibility of an approximate 10% increase in performance:

    "Basically the SNES is kind of hard for dynarec because :
    - Code can be automodifying (a code write itself).
    In an architecture like MIPS or ARM cpu, you cant do that (because of the pipeline and code CACHE/ data CACHE seperated) So emulator writer goes really simpler.

    --> One solution could be to emulate the code in RAM, and JIT the code in ROM.

    - The Snes cpu is 1.7 Mhz only : I bet for the moment it takes around 100 Mhz of the main cpu to emulate it (even less probably). The JIT would probably increase the performance by 2 or 3 on the cpu emulation part... but how much TYL would increase in performance... I am not sure.

    Most likely a 10% increase in performance globally ?
    Most of the emu that benefit from JIT are the cpu consuming one : N64 -> 80 Mhz MIPS
    GBA : 17 Mhz ARM cpu (ARM is annoying to emulate on MIPS : very costly)

    This kind of technique would be usefull for the coprocessor as Tinnus said."


    He also believes that if the graphics code was completely rewritten there would be a performance increase for the most popular roms:

    "A full rewrite of the chipset (DSP / FX) emulation using VFPU for math stuff should increase the performance by quite a bit.

    While the BEST/MOST popular games use it, it would require a LOT of dev to play 10 games.

    That's why yoyo and I never went on this road...
    Moreover, we had more priority at that time :-)"


    http://yoyofr.proboards44.com/index....4352305&page=3

    But that the sheer time and effort involved in coding these outweigh any potential benefit and that neither he nor Yoyofr have the time to undertake this.

    They have mentioned though that they would like to fix any current bugs (and there is a bug report thread going in the forum) so it is hoped that the "final release" if it is released will cover the known bugs in release 0.42.

    As to my motivation in writing this piece, well Yoyofr and Laxer3a have never been ones to openly advertise the fact that they would consider help on the project but I'll quote Laxer3a:

    "I am not sure neither yoyo and I want to go that far in tuning. If any good coder is interested to join in... May be worth sending a bottle to the sea actually. As the source matches the latest binary. "

    So if there is someone out there that would consider the above coding rewrites as a challenge they'd like to take on......

    http://yoyofr.proboards44.com ...
    by Published on August 11th, 2006 00:59

    Update from Strmnnrmn's blog:

    www.strmnnrmn.blogspot.com

    I've also updated page 4 of my last news post with some Q&A's about R7 taken from the Blog.

    http://www.dcemu.co.uk/vbulletin/sho...9&postcount=32

    From StrmnNrmn:

    'I'm getting close to finishing everything I want to get into R7. I've just spent a little time tidying up a few loose ends (little things like the way screenshots are handled). The one last substantial bit of work I want to get done is support for custom controller configs. I think this should be a few hours work, so I expect I'll finish this sometime on Saturday or Sunday, with a release following shortly afterwards.' ...
    by Published on August 7th, 2006 01:22

    From strmnnrmn's blog:

    http://strmnnrmn.blogspot.com/

    LOL I just realised I should have summarised the post for the tldr crowd.

    Basically R7 looks like having greater compatibility, more speed increases, and if all goes well the new release will be out by next weekend.

    For those of you who like the juicy details:



    More R7 Optimisations

    It's been a while since my last post, but I've still been hard at work with various optimisations for Daedalus R7.

    Although my main focus is on improving the dynamic recompiler, I've been looking at optimising a couple of other areas that I noticed were fairly expensive. The texture cache is one of the areas that I spent time tuning this week. This cache is used to avoid converting textures from the native n64 formats to psp formats every frame. I made a couple of fixes to improve the hashing function which gives much faster lookups in certain situations (such as tiled backdrops). I also provided an option to change the frequency at which the texture cache checks for updates to the textures. Many roms look fine when this check is entirely disabled, and this can give quite a nice speed boost.

    My main focus has continued to be on the dynamic recompiler. I've made a couple more bugfixes in this area. One bugfix involved detecting when roms were using self-modifying code. The fix involved dumping the contents of the dynarec cache so that the code is correctly regenerated for the updated instructions. This fix solves a couple of issues I was seeing with Quest64, and I'm sure it will help improve compatibility with a number of other roms too.

    The other dynarec issue I fixed was related to the way I was handling certain types of branch instructions. The MIPS processor has a set of 'branch likely' instructions which work slightly differently to regular branches and so I handle them separately in the dynamic recompiler. It turned out that I had forgotten to link together code fragments when they exited through a branch likely instruction. This fix gives a nice little speedup.

    The biggest bit of new development I've been doing on the dynarec is on optimising for various situations where I can determine the contents of a given register at the time I'm compiling the code. As an example, many roms use the following sequence to load an integer value from memory at a specific address:

    LUI $t0, 0x8033 // Load Upper Immediate - i.e. load t0 with 0x80330000
    LW $t0, 0x1234($t0) // Load Word - i.e. load t0 with the value at 0x80331234

    Previously I'd generate code for both of these instructions on the PSP. The LUI instruction is easy (if t0 is cached on the PSP then this is just one instruction). The LW is a lot more tricky. I have to call a function to convert the address on the n64 (0x80331234 in this case) to the address in the emulated memory on the PSP. Then I have to read from that address, or trigger an exception in the emulator if the memory address is invalid.

    With the changes I've just made, when I encounter the LUI instruction (or other instructions involving loading constant values into registers) I keep track of the fact that I've loaded t0 with 0x80330000. When I come to process the LW instruction, I can now determine that the desired address is 0x80331234. I can then map that address directly to the required location on the PSP, avoiding a function call in the generated code. By avoiding the function call I no longer need to flush cached registers back out to memory. Also, because I can tell in advance that the address lies in RAM (and isn't referencing a hardware register for instance) then I can also omit the code testing for an exception. Finally, in situations like the example above, I can don't need to generate any code for the initial LUI (as the register is immediately overwritten with the loaded value.)

    In summary this is a very nice optimisation - it generates fewer instructions (reducing the size of the dynarec code), it avoids unnecessarily flushing out cached registers, it avoids generating exception handling code, and it can eliminate redundant instructions (the initial LUI). In the best case, for 2 source instructions it will generate just 3 output instructions, compared to 12-13 for the unoptimised case.

    Unfortunately this approach only works with load and store instructions where the address can be determined in advance, but from the roms I've examined so far around 10-15% of the load/store instructions can be optimised in this way, which is enough to give a measurable benefit.

    I'm going to spend the rest of this week seeing which other parts of the dynarec engine can benefit from similar approaches. I have a couple of other features to implement (configurable controllers etc), if that all goes to plan I'll
    ...
    by Published on June 23rd, 2006 01:45

    Strmnnrmn has just posted the following on his blog:

    http://www.strmnnrmn.blogspot.com/

    Plans for R6

    I'm back from Spain now. I had a great time in Barcelona, it's a bit of a shame to be back

    I'm planning to have quite a quick turnaround on for the next release, i.e. hopefully I'll have something ready by the end of next week, or early July. I want to concentrate on fixing a bunch of graphical issues (adding new combine modes to fix various pink+black textures etc). I'm also going to look at reducing memory requirements - I think the stability problems associated with running the emulator with dynarec for an extended period of time are a result of running out of memory. This should also help to improve the Expansion Pak support. If I get enough time I'll look at adding support for configuring the controls on a rom by rom basis. Finally, I also want to look at improving savegame support.

    -StrmnNrmn

    PS Congrats Ghana + Australia ...
    Page 1 of 2 12 LastLast
  • Search DCEmu

  • Advert 3