StrmnNrmn Wrote:I had planned on posting this update on Monday, but I've spent the last couple of nights catching up on a few games that I've not had chance to play since they were released (Crackdown on the 360 and Afterburner : Black Falcon on the PSP for the curious :)
For R11 I'm hoping to fix the Expansion Pak support for once and for all. Memory is currently very tight, so I need to look at shaving off a few hundered KB here and there. Almost all the memory Daedalus uses is allocated up front - there are very few dynamic allocations at runtime, with the biggest culprit being the texture cache. So for R11 I want to introduce a pooled allocator for the texture cache, which will mean that when it runs out of memory, you just get white textures appearing rather than a hard crash.
The other feature I want to improve in R11 is the way that global settings and per-rom settings are handled. At the moment Daedalus discards any changes to settings that you make when you restart your PSP, and it can be incredibly tedious setting things up every time you run a game. This is quite a small feature to add, but I think it will make the emulator much nicer to use.
Behind the scenes, I want to spend a short while working on some scripts to handle packaging new releases for distribution. Current I do all of this by hand, and it's one of the things I least enjoy about the project. Hopefully, the more automated I can make this, the more frequently I'm likely to release builds :)
I'd like to get all these changes done and release R11 within a couple of weeks. I have a couple of busy weekends coming up, so I'm not going to specify an exact date. You can expect it before May though (I'll try not to be a couple of days late this time :)
R11 is essentially going to be a compatibility release - hopefully the Expansion Pak support will lead to a few more roms running (Majora's Mask being one I've already verified). Looking further ahead, R12 will be back to concentrating on speed (as it happened, R10 achieved a 10-15% speedup without having implemented the majority of the optimisations I had planned :)
So lets put it this way, StrmnNrmn plans on working on R11 this next few weeks wanting to fix the Expansion Pak once and for all making more roms compatible, and he will also be working on per-rom settings, so when you change a setting it will stay changed.
Then after R11 he will be back to working on speed improvements for R12 (And that's what wee like to hear) ;)
Now this is what I like to hear :yipi: :yipi: :yipi: :yipi: :yipi: :yipi: :yipi: :yipi: :yipi:
QJ Wrote:PSP-Generation claims Dark_Alex's planning to push 3.30 OE custom firmware out the receiving door within "48-72 hours". Given the timings between the news on April 1 (it's just a calendar date, after all), and the 3.30 decrypter, this claim is quite credible on the best analysis.
The devil is in the details, though. PSP-Gen explains that Dark_Alex found 3.30 using up quite a lot of the PSP's flash memory, which is complicating efforts to add bonus functions. Hence, the 48-72 hour thing: he's trying to make up his mind between releasing 3.30 OE as is, and add bonus functions through patches later, or release it later with the bonus functions built in.
Well, so far as current PSP games aren't demanding 3.30, maybe it can wait, but with the improvements to movie playback...
QJ Wrote:This program was originally created by Tommydanger to help those who are rather afraid of installing new firmwares to DevHook. And anyone who has used this before will agree that it is quite noob-friendly and it takes away all your homebrew fears. That doesn't mean though that you will not take precautions.
Anyway, Sleepy566 said that as of the moment, there are no known issues for DevHook Firmware Installer v0.6h. Everything is ready to run, as the coder included the customized Devhook 0.52010000. And as such, it should run on all known firmwares. Below is the complete changelog for this version. Please make it a point to browse through the Readme file before using this.
Version 0.6h
* Bug fixes corresponding to previous version's additions
* Added newest Devhook and folders for all the firmwares you could decrypt (though unsupported)
Version 0.6g
* Added full support for 3.30 (didn't forget anything this time)
I finally managed to download the 3.30 update so I could have a little look at some RCOs...
visualizer_plugin.rco
Firstly, I say, there's nothing to be excited about this one. All the RCO contains is 14 images (I checked by searching for the signature; the header indicates that no more than 15 images are in there though). Also contains what appears to be a "blank" (unused/useless) page resource.
As for the purpose of the images, I don't know. I guess it's possible that the some of them are used in the visualizations, but making your own effects won't be possible by editing the RCO.
topmenu_plugin.rco
The 1 or 2 extra page resources present in the 3.10 topmenu (which was what caused the problems) aren't present in the 3.30 topmenu, and the 3.30 topmenu's header is only 668 bytes longer than the 3.0x one (both unpacked), so yes, 3.30 OE will almost certainly be customizable :)
Interestingly, though, the icons in the 3.30 topmenu take up less space than the 3.0x topmenu
Since topmenu's a large RCO, I'm too lazy to do any further investigation, but I can say that custom icons will most likely work on 3.30 :D
In what could be the most embarrassing exploit to impact Windows Vista since its commercial launch in January, security engineers at McAfee’s Avert Labs confirmed today - and posted the video to prove - that the operating system can be caused to enter an interminable crash-restart-crash loop, by means of a buffer overflow triggered by nothing more than a malformed animated cursor file.
It isn’t even a new exploit, as researchers with eEye discovered in January 2005. At that time, Microsoft acknowledged it affected versions of the operating system from the first edition of Windows 98 through to early releases of Windows XP, though it stated at the time XP SP1 was unaffected.
But apparently after researching field reports of limited attacks, Avert Labs discovered an apparently similar exploit using .ANI files impacts XP SP2 and Vista, as well as Windows 2000 SP4 and versions of Windows Server 2003 from the initial release through to SP1. Avert Labs stated XP SP1 and versions since were unaffected, though Microsoft warned the exploit does affect XP SP2.
If both firms’ accounts are correct, Microsoft may have fixed the problem with XP SP1 in 2005, and inadvertently un-fixed it sometime afterward.
Avert Labs’ video of the incident, posted to YouTube, shows a Vista system wherein the test file apparently trying to load the custom animated cursor. When the operating system detects a crash, it first tries to save vital data prior to a restart sequence - one of Vista’s newer features. It then informs the user that Windows Explorer has crashed.
But in trying to restart Explorer, the restarting crashes itself, sending Vista into a tailspin from which the only escape appears to be the off button.
The mouse input routines in Windows are designed with the intention of being relatively failsafe. That’s why when the system appears to hang, you can often still move your mouse pointer. As I’ve personally witnessed on many occasions with Windows XP, it’s possible for a smaller OEM’s mouse driver - often an unsigned one - to trigger a similar tailspin loop that crashes Windows Explorer repeatedly. In Windows, a lot depends on the mouse pointer’s very existence.
So if a customization feature can impact the mouse pointer’s ability to function, the integrity of the entire system can be jeopardized. With my own systems, drivers and services that are unfriendly to one another - such as Stardock’s CursorXP animation program trying to co-exist with a Synaptics Pointing Device driver on a notebook with ATI Mobility Radeon 9600 graphics - can trigger an Explorer tailspin.