tag:blogger.com,1999:blog-130945052024-03-07T05:47:38.968+00:00Retro Console DevNews and updates on Daedalus PSP and various notes on emulator development.StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.comBlogger104125tag:blogger.com,1999:blog-13094505.post-6746084154194030052012-08-16T08:57:00.001+01:002012-08-16T08:57:16.601+01:00n64jsWow, yet again it's been ages since I posted.
I just wanted to share some information about a project I've been tinkering with in my spare time - I ported Daedalus to JavaScript. You can try it out here: <a href="http://hulkholden.github.com/n64js/">http://hulkholden.github.com/n64js/</a>.<br />
<br />
Be warned - even though it's based on Daedalus, a lot of features are unimplemented, and there are a whole host of new bugs that need fixing. It's also pretty slow (but not as slow as you might think, given that it's written in JavaScript).<br />
<br />
I'm going to write up some notes about the implementation over at <a href="http://n64js.blogspot.co.uk/">http://n64js.blogspot.co.uk/</a>. Otherwise I'll probably see you back here in a few years ;)StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com4tag:blogger.com,1999:blog-13094505.post-18967617563393256082008-11-27T18:56:00.001+00:002008-11-27T19:36:59.534+00:00Yes, I am aliveNo, I didn't choke on a mince pie :)<br /><br />I'm sorry for the lack of updates, both to the blog and to Daedalus. I've been working on Daedalus for about 10 years now, and those that have followed the project from the beginning will know that I have fairly regular periods of 'radio silence' followed by bursts of activity. I have lot of inertia, so once my interest shifts elsewhere it can take a long time to get me back on track. That's just the way I am.<br /><br />This time around it's because I've been really busy with work. I don't want to go into specifics, but for the past couple of years I've been working on a high profile game, and since January most of my energy has gone into helping to get it finished.<br /><br />I am unbelievably out of touch with the PSP scene. Recently, Kreationz got in touch to tell me about the progress that has been made with DaedalusX64. I was really pleased to hear that the project was being actively updated, particularly because I have a lot of respect for the people involved. The whole reason for making Daedalus open source was to give people the opportunity to learn from the source code and update it as needed, so it's great for this to be happening.<br /><br />I can't guarantee that I'll have the time to actively help with DaedalusX64, or even that I'll be able to regularly update this blog. I thought it would be a good idea to give my public backing to DaedalusX64 so that the team can get on with rolling out updates. I probably won't be making a PSP release of Daedalus any time soon.<br /><br />For what it's worth, I'm currently working on a new port of Daedalus. I'm going to keep the target platform secret for now, but I think it's very exciting. At the very least it means that I'm working on Daedalus again - I'm hoping to keep merging changes from DaedalusX64 back into the Daedalus source, and hopefully provide DaedalusX64 with one or two fixes of my own. <br /><br />That's all for now. Apologies in advance if the next blog post is in December 2009 :)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com26tag:blogger.com,1999:blog-13094505.post-61723357496157438852007-12-24T13:17:00.000+00:002007-12-24T14:00:05.960+00:00Yuletide UpdateIt's been a while since the last update so I wanted to give some news on how things are going with work towards the next release.<br /><br />I've spent a lot of time working on getting the HLE audio code working on the Media Engine. I've been making steady progress, but it's been taking longer than I initially expected. Fortunately, I'm very close to getting all of the audio processing moved over to the ME - in fact I believe I have just one significant bug left to fix.<br /><br />The issue seems to be a very odd synchronisation bug which causes the emulator to lock up when running the audio processing asynchronously. As with many of these types of bugs, it's proving quite hard to track down because as soon as I change the code to debug the problem, the issue goes away. A true <a href="http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs">Heisenbug</a> :( <br /><br />What's particularly annoying is that the bug is stopping me from measuring how much of a difference running the audio code on the ME makes. Hopefully I'll be able to fix the bug over the Christmas break and be able to publish some timings over the new year.<br /><br />As part of this work, I've also been writing a general-purpose 'job manager', which coordinates batches of work between the main CPU and the ME. The idea is to build on top of J.F.'s MediaEngine.prx to provide a simple interface for queing up and dispatching work asynchronously. When a job is added to the queue, a flag indicates whether the job is suitable for running on the ME, or whether it should just be run asynchronously on the main CPU instead.<br /><br />Initially just the audio processing will run through the job manager on the ME, but eventually it should be possible run other pieces of work asynchronously too. I'm hoping that it will eventually be possible to move parts of the HLE graphics processing to run asynchronously too, but I need to investigate things a bit more first. That's a job for future releases however.<br /><br />Anyway, that's all for now. I'm off to eat mince pies and watch The Great Escape on tv. Merry Christmas everyone :)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com350tag:blogger.com,1999:blog-13094505.post-9627708297086932862007-11-25T23:21:00.001+00:002007-11-26T00:12:02.035+00:00R14 ProgressIt's been a while since I talked about R14 so I wanted to post a quick update on what I've been doing. <br /><br />The <a href="http://strmnnrmn.blogspot.com/2007/11/media-engine.html">Media Engine</a> work has been going well. The <a href="http://strmnnrmn.blogspot.com/2007/11/media-engine-progress.html">job manager</a> I talked about last week is now fairly functional and handles executing the audio upsampling code in 3 different modes: synchronously, asynchronously on the main processor, and asynchronously on the ME. <br /><br />It's taken me a little longer to get the audio upsampling code working smoothly on the ME. I decided to focus on this initially (rather than Azimer's Audio HLE code) as it's a lot simpler and more self contained, but getting it working on the ME without any glitches required a little bit of work. I had to rewrite the simple ring buffer I was using to be <a href="http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms">lock-free</a>. This is straightforward when dealing with a single reader thread and a single writer thread on the same processor, but a little more care is required when the reader and writer are operating on separate cores without cache coherency. I think getting this running glitch-free has helped prepare me well for the bigger task of getting Azimer's HLE code running asynchronously on the ME. I'll be working on this next.<br /><br />Besides the ME work, I've had an interesting diversion getting some new font rendering working in Daedalus. I saw on the <a href="http://forums.ps2dev.org/viewtopic.php?t=9367">ps2dev.org forums</a> that BenHur had released a <a href="http://www.psp-programming.com/benhur/">library</a> for rendering text using the PSP's built in fonts. I've always been a little unhappy with Daedalus's text rendering, and thought this would be a good opportunity to improve it. Here's a screenshot of the UI using BenHur's intraFont library (click through for a better-looking unscaled version):<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXOYj0KgEKQwc3oMZYvZo2Iy7lLofHBR-ByBgjfb_7JxGvGTMBDKxvEvVK5B-QHsYKaHQsCsnF8yTSPoiukirL0EDZO0QI1pMlgSCxxyafwQK2BifiM8OZpaWUVTijM_2JFtRY0w/s1600-h/sd0024.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXOYj0KgEKQwc3oMZYvZo2Iy7lLofHBR-ByBgjfb_7JxGvGTMBDKxvEvVK5B-QHsYKaHQsCsnF8yTSPoiukirL0EDZO0QI1pMlgSCxxyafwQK2BifiM8OZpaWUVTijM_2JFtRY0w/s400/sd0024.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5136933015692545666" /></a><br /><br />I think this is looking a lot better than the previous font. The drop shadows really help make the text more readable. I also support multiple fonts for the first time, so the header text actually looks like header text :)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com69tag:blogger.com,1999:blog-13094505.post-77289712946156547812007-11-19T23:14:00.000+00:002007-11-19T23:23:00.688+00:00And the winner is...This has been one of the hardest posts I've had to write, because I know whichever entry I pick as winner of the <a href="http://strmnnrmn.blogspot.com/2007/11/icons-for-daedalus.html">icon competition</a>, a lot of people are going to be disappointed that I didn't pick their favourite.<br /><br />Trying to select a winner has forced me to think about what I wanted to get out of this competition. On the surface, the main goal of the competition was just to replace the ugly default icon on the PSP's XMB. However as I've checked out all the entries over the past couple of weeks, I've come to realise that the main objective of the competition should be to define an <span style="font-style:italic;">identity</span> for Daedalus.<br /><br />In the end, one of the main criteria I've used to select the winner is how well the design works as a logo, or identity, for the project as a whole. For this reason I've picked <span style="font-weight:bold;">Patrick Ahmann's</span> design:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRO7Mx7UWz5m16ccNViXfhJnuMNk-_EU4EoAYZ6GJUEa2oAnQsBPtZbd4COGmNAuEbXJOs47gNUunDwYfdgdn304W75rHn5PwvtypMLp5P3D1RclPAXKT5BoBb70ez9K5Wvzr03Q/s1600-h/daedalus_background.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRO7Mx7UWz5m16ccNViXfhJnuMNk-_EU4EoAYZ6GJUEa2oAnQsBPtZbd4COGmNAuEbXJOs47gNUunDwYfdgdn304W75rHn5PwvtypMLp5P3D1RclPAXKT5BoBb70ez9K5Wvzr03Q/s400/daedalus_background.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785925651041698" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXmN7rwXDRJ6TVCbjyP69CUUFCi5-GLIWZwkDMZHuk91cEc0bvHr1j1to1mmucim1xCmVY8GQTso1Yt_EIGdRa-Nw0XC5CGRm9jqshjGo3zzMSFOHCrF49wzfWgpTom9XrWKL39g/s1600-h/daedalus_icon.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXmN7rwXDRJ6TVCbjyP69CUUFCi5-GLIWZwkDMZHuk91cEc0bvHr1j1to1mmucim1xCmVY8GQTso1Yt_EIGdRa-Nw0XC5CGRm9jqshjGo3zzMSFOHCrF49wzfWgpTom9XrWKL39g/s400/daedalus_icon.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785929946009010" /></a><br /><br />I think Patrick's design is wonderfully clean and stylish, and the colours look especially crisp and vibrant on the PSP's screen*. The typography, particularly for the 'daedalus' logo is very simple and distinctive and I think it would work well as a logo on the web. What's more, I got quite excited about using the cog motif on the logo as a progress indicator on loading screens :)<br /><br />So, well done Patrick!<br /><br />I want to say a big 'thank you' to everyone who contributed. Many people put a lot of work into this and I'm really sorry that I could only pick one winner. I think the quality of the final 10 was excellent, so if you disagree with my choice hopefully there's something there for you :)<br /><br />-StrmnNrmn<br /><br />*annoyingly Blogger insists on downsampling the images above slightly, so they look a little fuzzy. Click through for the original versions...StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com36tag:blogger.com,1999:blog-13094505.post-28460321567948354692007-11-17T12:50:00.000+00:002007-11-20T12:04:16.584+00:00Icon Competition - ShortlistI've just finished compiling a shortlist of what I think are the 10 best submissions for the <a href="http://strmnnrmn.blogspot.com/2007/11/icons-for-daedalus.html">icon competition</a>.<br /><br />I received just under 200 entries in total; I've been blown away by the response. Picking just 10 entries has been very difficult. In the end I had a 'longlist' of around 30 entries which I thought were superb, and it's taken me over an hour to whittle that down to just 10 entries.<br /><br />Here is my shortlist, presented in the order they were submitted. Feel free to discuss these in the comments - I'll be reading your comments over the weekend, and I'll pick a final winner on Monday. <br /><br />Thanks to everyone who entered - you're awesome!<br /><br /><br /><br />-StrmnNrmn<br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPbghmiywMVtu6AvgaT_Tb5RiJMzKxa7a66seW7HuTt3dQBXfx0n9YUJbcto3PgTGgTZJLFlSiPI7-TgPAkTxhoFiaAxu4pBGV4HAMjwb8uUolXbg5YKRzsFJKOcqESyBRjDd2Aw/s1600-h/Concoursicon1.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPbghmiywMVtu6AvgaT_Tb5RiJMzKxa7a66seW7HuTt3dQBXfx0n9YUJbcto3PgTGgTZJLFlSiPI7-TgPAkTxhoFiaAxu4pBGV4HAMjwb8uUolXbg5YKRzsFJKOcqESyBRjDd2Aw/s400/Concoursicon1.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133784912038759746" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirqxqmDUA8OKpNAYh2vEavfdfv5kI-r4P4r2SMWx_colSLDRniQIBYtEnp4k_R3R87bnj-inbtNwtyYbDgzMTZC6XK8OuKU5Beltjugzh6p3BoB3fBEiVbAk14TiS9it5WORY1Rg/s1600-h/Concoursicon0.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirqxqmDUA8OKpNAYh2vEavfdfv5kI-r4P4r2SMWx_colSLDRniQIBYtEnp4k_R3R87bnj-inbtNwtyYbDgzMTZC6XK8OuKU5Beltjugzh6p3BoB3fBEiVbAk14TiS9it5WORY1Rg/s400/Concoursicon0.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785040887778642" /></a><div align="center"><b>Cladil</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEYbZ-G17oIoZAALY4cTFVujigCa2QnjXBDdeM7qBXovPgD0o0Q_C-Vbqww9rttQixm7cNXBKwOnDAWqy48_KuceF-0WoUJE0DbM3JrbZBWwoHTEa-MaddycJikBgUF1c1x0XHVw/s1600-h/Fond.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEYbZ-G17oIoZAALY4cTFVujigCa2QnjXBDdeM7qBXovPgD0o0Q_C-Vbqww9rttQixm7cNXBKwOnDAWqy48_KuceF-0WoUJE0DbM3JrbZBWwoHTEa-MaddycJikBgUF1c1x0XHVw/s400/Fond.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133787145421753954" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2ay5MtQv6V8IucQA6VTHs6QOJA1bgzPVWz1vRgcueoQFUm3qx1xcYEdUF3_9xlL-r_AOJ_dRLTKEV6Zm4nGwrDA7Vju7O1-jf3WhvnU2knIltEos6jRybjgSg03S2D1vASMvzuQ/s1600-h/Icone.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2ay5MtQv6V8IucQA6VTHs6QOJA1bgzPVWz1vRgcueoQFUm3qx1xcYEdUF3_9xlL-r_AOJ_dRLTKEV6Zm4nGwrDA7Vju7O1-jf3WhvnU2knIltEos6jRybjgSg03S2D1vASMvzuQ/s400/Icone.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133787149716721266" /></a><div align="center"><b>Pleaser</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgg2dX7Ga_uQpO-WZax6_uGsYVmwgGXGr6CA2A83bxLLsG6n4YWy2lgnPulSb9LepsXeAcN3x-LHM-SzfTeNeJJpJ5qRC4IMMWzUCHsjwDhli5-xpDH_N4UZuW42Stvqqr_DrknpA/s1600-h/PIC1.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgg2dX7Ga_uQpO-WZax6_uGsYVmwgGXGr6CA2A83bxLLsG6n4YWy2lgnPulSb9LepsXeAcN3x-LHM-SzfTeNeJJpJ5qRC4IMMWzUCHsjwDhli5-xpDH_N4UZuW42Stvqqr_DrknpA/s400/PIC1.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786840479075874" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcEL_QBIF_uz1765Io8YRxGeHqd-Xg-bQ5F9F2lcs_rJ7-Ikr1PoqkLq7Mpl3uKCt7tWS-ZPhqd1gfDZ8Lg_0FaebD22rbaZfoki894Hl9r8Ng7NPOiSfIQpSPoeGxVq7795njuA/s1600-h/ICON0.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcEL_QBIF_uz1765Io8YRxGeHqd-Xg-bQ5F9F2lcs_rJ7-Ikr1PoqkLq7Mpl3uKCt7tWS-ZPhqd1gfDZ8Lg_0FaebD22rbaZfoki894Hl9r8Ng7NPOiSfIQpSPoeGxVq7795njuA/s400/ICON0.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786844774043186" /></a><div align="center"><b>Pharonyk</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfa5g1lTobvjX0jwRSvVViddh2NDiCpkDMG8FzFKmNfJARTv-TXlLQCVLTpAuZQJzIhhYUVQ7_DgnCZlptAcWJ-hsLgir4D8ubMhyphenhyphen9o7xusaHzd4Q_eAwKaVcTaa5W7ZTepFjfNw/s1600-h/Background.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfa5g1lTobvjX0jwRSvVViddh2NDiCpkDMG8FzFKmNfJARTv-TXlLQCVLTpAuZQJzIhhYUVQ7_DgnCZlptAcWJ-hsLgir4D8ubMhyphenhyphen9o7xusaHzd4Q_eAwKaVcTaa5W7ZTepFjfNw/s400/Background.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786853363977794" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMG2zppfAa-YUfDGeL5Dg1tWnyqbxQ_oYPUZ7FO06q-6Mzn6k0XW5YYXg-5SvTE0FmigxDB5mapoKhMgqJwW0JFreWIYuxZMtNzmSLSFXJxLGyy0-isHzfZAQJFJyWd_b9WstjtQ/s1600-h/Icon.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMG2zppfAa-YUfDGeL5Dg1tWnyqbxQ_oYPUZ7FO06q-6Mzn6k0XW5YYXg-5SvTE0FmigxDB5mapoKhMgqJwW0JFreWIYuxZMtNzmSLSFXJxLGyy0-isHzfZAQJFJyWd_b9WstjtQ/s400/Icon.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786853363977810" /></a><div align="center"><b>Steven La</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvGeGkQOZB7h-IIJmj1d630Cymuyb3ZNU9EBCpWuaeXBQqRzrwlkarbS73U7eoIzfg9d_8tpi-l6jRA0XbFM9J-UHaJmCVaKIk_hWf97AHTdDDdjZUCOorZjSgJhRUTe4EdSO8ZA/s1600-h/bg02.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvGeGkQOZB7h-IIJmj1d630Cymuyb3ZNU9EBCpWuaeXBQqRzrwlkarbS73U7eoIzfg9d_8tpi-l6jRA0XbFM9J-UHaJmCVaKIk_hWf97AHTdDDdjZUCOorZjSgJhRUTe4EdSO8ZA/s400/bg02.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786462521953762" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyj4hoPz6Xzq9-Pm2O90BbhfpBQ8UMO50Kc-AKFVLjAQDtBuXalDkIhg4HRnsdWismH5UDFJEvNLJFrdkuhflIqIXb0B3vQN9ZTcQ4Bdo8dYyfxEyJ1HLYxXvD-msIWy5tzbDZ0Q/s1600-h/icon01.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyj4hoPz6Xzq9-Pm2O90BbhfpBQ8UMO50Kc-AKFVLjAQDtBuXalDkIhg4HRnsdWismH5UDFJEvNLJFrdkuhflIqIXb0B3vQN9ZTcQ4Bdo8dYyfxEyJ1HLYxXvD-msIWy5tzbDZ0Q/s400/icon01.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786475406855666" /></a><div align="center"><b>Victor Aguirre</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEin1PkkLvOuG0BzKUcoHKm5wzu7n5bdjsayaY47OSdQSwIsvCG6yWQ1UXWEc7szNVeXXdJLIcthlHUEGRGIK8JpWp13BMKTz0i1LuWGUaDGk7zNBooNcozS0PgdOm35jXj5TXSaYg/s1600-h/Daedalus2.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEin1PkkLvOuG0BzKUcoHKm5wzu7n5bdjsayaY47OSdQSwIsvCG6yWQ1UXWEc7szNVeXXdJLIcthlHUEGRGIK8JpWp13BMKTz0i1LuWGUaDGk7zNBooNcozS0PgdOm35jXj5TXSaYg/s400/Daedalus2.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786479701822978" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_YnrFrvdYq5RDYM61Aad-_vc4SPDHhyphenhyphenFykeS5ak_NmbRpE8QHYjTxlLXKNPeyL3O1WTyFCK4SQi-5wHpur86kUMitAlD9ns9_enIFjMKg7qNLRRZbEGYONF3fbUeJJpVMzErrBA/s1600-h/Daedalus_mini2.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_YnrFrvdYq5RDYM61Aad-_vc4SPDHhyphenhyphenFykeS5ak_NmbRpE8QHYjTxlLXKNPeyL3O1WTyFCK4SQi-5wHpur86kUMitAlD9ns9_enIFjMKg7qNLRRZbEGYONF3fbUeJJpVMzErrBA/s400/Daedalus_mini2.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133786479701822994" /></a><div align="center"><b>Joël Dos Santos</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwLOsRuzVn-Ggc_WLMw3ylDBM_I3C9Kf7tFJGF6_9n3mESh_3cDb2QyCcT8r5Msr5tfmt_LyKXT65ChJEp8HVErghr61CkrdjJ3QBtiplKeGbXdq5uolDOU86yr-MopoPM_DsTQQ/s1600-h/PIC1.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwLOsRuzVn-Ggc_WLMw3ylDBM_I3C9Kf7tFJGF6_9n3mESh_3cDb2QyCcT8r5Msr5tfmt_LyKXT65ChJEp8HVErghr61CkrdjJ3QBtiplKeGbXdq5uolDOU86yr-MopoPM_DsTQQ/s400/PIC1.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785934240976322" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdmRvrKvnsBBXgP1V3n58g4La0sn_VsHlRici6HgVfy3m876mGfu_5kj7JqxyljrkAsEFnjBb8ShO9b1FbCv6Z2V6OEvgDcm90DLaRPwK8NJJuvGtUYf6xVhQ2hUexDl5z46WgjQ/s1600-h/ICON0.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdmRvrKvnsBBXgP1V3n58g4La0sn_VsHlRici6HgVfy3m876mGfu_5kj7JqxyljrkAsEFnjBb8ShO9b1FbCv6Z2V6OEvgDcm90DLaRPwK8NJJuvGtUYf6xVhQ2hUexDl5z46WgjQ/s400/ICON0.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785947125878226" /></a><div align="center"><b>Jay Mc</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRO7Mx7UWz5m16ccNViXfhJnuMNk-_EU4EoAYZ6GJUEa2oAnQsBPtZbd4COGmNAuEbXJOs47gNUunDwYfdgdn304W75rHn5PwvtypMLp5P3D1RclPAXKT5BoBb70ez9K5Wvzr03Q/s1600-h/daedalus_background.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRO7Mx7UWz5m16ccNViXfhJnuMNk-_EU4EoAYZ6GJUEa2oAnQsBPtZbd4COGmNAuEbXJOs47gNUunDwYfdgdn304W75rHn5PwvtypMLp5P3D1RclPAXKT5BoBb70ez9K5Wvzr03Q/s400/daedalus_background.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785925651041698" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXmN7rwXDRJ6TVCbjyP69CUUFCi5-GLIWZwkDMZHuk91cEc0bvHr1j1to1mmucim1xCmVY8GQTso1Yt_EIGdRa-Nw0XC5CGRm9jqshjGo3zzMSFOHCrF49wzfWgpTom9XrWKL39g/s1600-h/daedalus_icon.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXmN7rwXDRJ6TVCbjyP69CUUFCi5-GLIWZwkDMZHuk91cEc0bvHr1j1to1mmucim1xCmVY8GQTso1Yt_EIGdRa-Nw0XC5CGRm9jqshjGo3zzMSFOHCrF49wzfWgpTom9XrWKL39g/s400/daedalus_icon.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785929946009010" /></a><div align="center"><b>Patrick Ahmann</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEingSRipBme3_9xRUuKvEKQ0wi6G3aH3imS_Od_zLPrV4fwBlCRDt8oZuBW-FFaA2F-up8rd14oNlZayo8oUh6ME92rXSNKVuP9oDtIZQ2uvRIwclbg50D4wqJnOIlr_GMLVCO4kQ/s1600-h/base_skin_dedalus.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEingSRipBme3_9xRUuKvEKQ0wi6G3aH3imS_Od_zLPrV4fwBlCRDt8oZuBW-FFaA2F-up8rd14oNlZayo8oUh6ME92rXSNKVuP9oDtIZQ2uvRIwclbg50D4wqJnOIlr_GMLVCO4kQ/s400/base_skin_dedalus.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785491859344770" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjadM9dlfQUtRNlB7jheb2a19qk400rNfLAYUKMWLutaj6vVCa3-nVRJu5kZ-91CoyNbTjWs0_WYU7rx5d_T2lazA2oo4oXcIi9SHSKRrqL6OpXatc-yj5FrixY4KaBdBWE45haZA/s1600-h/icone_daedalus.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjadM9dlfQUtRNlB7jheb2a19qk400rNfLAYUKMWLutaj6vVCa3-nVRJu5kZ-91CoyNbTjWs0_WYU7rx5d_T2lazA2oo4oXcIi9SHSKRrqL6OpXatc-yj5FrixY4KaBdBWE45haZA/s400/icone_daedalus.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785496154312082" /></a><div align="center"><b>Hykypoo</b></div><br /><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiajU28WYEvi3a43ohQwZKxa_GVazT1FxFh3PIbcsJZdTUGlrYCa4WVUKOkJWrq2ddD6F-yAkM-UphyphenhyphenWl4FdAhFz1_fqT4VdVijNSRATtjSqqXAwILMv80nds6JRpgumDjPHza1Qw/s1600-h/DAEDALUS.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiajU28WYEvi3a43ohQwZKxa_GVazT1FxFh3PIbcsJZdTUGlrYCa4WVUKOkJWrq2ddD6F-yAkM-UphyphenhyphenWl4FdAhFz1_fqT4VdVijNSRATtjSqqXAwILMv80nds6JRpgumDjPHza1Qw/s400/DAEDALUS.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785418844900722" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHdSxdpACp_Trk_tjop2e9j8hTd02nK2KjsGWiXppoWdiCj-BqTQ7ViacmjsTIbvX14JMiROLB-5XZTTc8QdaOvDY01IBrJgzzL57sb6Nyk97ynFk0mFquRnxU2jOTfVtOXcm8Mg/s1600-h/DAEDALUSICON.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHdSxdpACp_Trk_tjop2e9j8hTd02nK2KjsGWiXppoWdiCj-BqTQ7ViacmjsTIbvX14JMiROLB-5XZTTc8QdaOvDY01IBrJgzzL57sb6Nyk97ynFk0mFquRnxU2jOTfVtOXcm8Mg/s400/DAEDALUSICON.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5133785414549933410" /></a><div align="center"><b>juniorslick363</b></div><br /><br /><b>Edit 20/11/2007 12:00</b> Fix Pharonyk's name.StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com78tag:blogger.com,1999:blog-13094505.post-4126389863473924542007-11-16T13:49:00.000+00:002007-11-16T13:56:52.065+00:00Last call for icons+backgroundsJust a reminder that today is the last day for sending in your entries to the <a href="http://strmnnrmn.blogspot.com/2007/11/icons-for-daedalus.html">icon competition</a>. I'll be making the shortlist sometime tomorrow morning, so provided you get your entry to 12pm (that's noon - GMT!) on Saturday it will probably be included.<br /><br />Once I've made a shortlist of what I feel are the 10 best submissions, I'll post them up here so that people can give their thoughts, before I pick a final winner on Monday.<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com9tag:blogger.com,1999:blog-13094505.post-86631796234456892722007-11-13T23:31:00.000+00:002007-11-13T23:56:59.220+00:00Media Engine progressOver the weekend I <a href="http://strmnnrmn.blogspot.com/2007/11/media-engine.html">described my plans</a> for getting audio list processing working on the PSP's Media Engine. I'm making some decent progress so far. I've got Daedalus loading a <a href="http://forums.ps2dev.org/viewtopic.php?p=60638#60638">kernel mode PRX</a> to handle the ME nitty gritty, and I've managed to execute some test code on the ME successfully.<br /><br />I've spent some time reviewing the audio code, trying to figure out if any bits are particularly amenable to running asynchronously, and trying to figure out if there is anything that is going to cause any problems when running this code on the ME. Fortunately it looks like all of Azimer's audio code is very straightforward C so there should be no problems getting it running on the ME once the synchronisation issues are dealt with. I've also realised that alongside the audio list processing there is also some expensive 44kHz upsampling code which will run very nicely on the ME too.<br /><br />I have the feeling that debugging code on the ME is going to be particularly painful, so I want to try and catch as many of the obvious synchronisation bugs as early as possible. This evening I've started writing a job manager to 'simulate' executing code on the ME. The manager simply creates a thread which sits and waits for jobs to come in, mimicing the behaviour of the mediaengineprx. Once I've got the audio list processing running correctly through the job manager, I can easily switch things over to get these jobs running on the ME in parallel to the main core. That's the plan, anyway :)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com23tag:blogger.com,1999:blog-13094505.post-59725775968715225682007-11-11T13:31:00.000+00:002007-11-11T13:43:01.483+00:00Icons update (part 2)!..And the last update today (I promise!) <br /><br />I just wanted to say that I've now received about 100 entries for the <a href="http://strmnnrmn.blogspot.com/2007/11/icons-for-daedalus.html">icon competition</a>. I'm about halfway through the list so far; apologies if I've not responded to your entry yet.<br /><br />I've had a lot more entries than I was expecting. Originally I was planning on posting all the entries so that people could comment on their favourites before I picked a winner. There are too many entries for me to be able to do that, so next weekend I'll pick my favourite 10 and show them instead.<br /><br />I've had <span style="font-weight:bold;">lots</span> of entries from readers of <a href="http://www.pspgen.com/">PSP-Generation</a>, so a big 'merci beaucoup' for that. It's certainly helping exercise my rusty French :)<br /><br />There's just under a week left before the competition ends, so be sure to get your submission in shortly. Thanks for all the entries so far!<br /><br />-StrmnNrmn<br /><br />PS Remember it's 'd<span style="font-weight:bold;">ae</span>dalus' and not 'd<span style="font-weight:bold;">ea</span>dalus'. It's an easy mistake to make :)StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com17tag:blogger.com,1999:blog-13094505.post-36100030843715776502007-11-11T13:22:00.000+00:002007-11-11T13:28:42.562+00:00Media EngineEarlier I <a href="http://strmnnrmn.blogspot.com/2007/11/r13-issues-r14-plans.html">discussed my plans</a> for getting Daedalus's audio processing working on the PSP's Media Engine.<br /><br />As I mentioned in that post, it's not just a case of changing some compiler setting to get this working. I've not spent much time investigating the ME so I may be wrong on a few of these points, but here are the current issues that I think need solving.<br /><br />Firstly in order to access the ME I need to be running in kernel mode. This requires either running Daedalus in kernel mode, or (preferably) creating a kernel mode PRX that encapsulates the required functionality. I <i>think</i> kernel mode rules out anyone running with v1.50 firmware (hence my <a href="http://strmnnrmn.blogspot.com/2007/11/firmware-poll.html">earlier post</a> - please respond to the poll if you haven't already done so!) Maybe one of the more savvy psp developers out there can correct me on this? If no-one is using v1.50 any more then maybe it isn't even an issue.<br /><br />Another problem is that although the ME is essentially the same processor as the main core, it has a different memory map. This means that things like the VRAM is invisible to the ME, so any code ported to run on the ME would have to be written to operate on main memory. This isn't an issue for Daedalus's audio list processing, but it would cause problems if I wanted to move display list processing to the ME too. <br /><br />Touching on the memory map issue, another problem is the lack of cache coherency between the two cores. I need to be careful when accessing the same areas of memory with both cores to correctly flush and invalidate the data caches. Ideally any shared memory should be kept to a minimum, but this is easier said than done when porting existing code, rather than writing new code.<br /><br />For a similar reason, any code which needs to run on the ME should avoid making any calls to the runtime library, including doing any system memory allocation. System calls are also ruled out. This is fairly easy to guarantee if you're writing new code, but again, it's a lot harder if you're porting existing code.<br /><br />I think that's most of the issues from the hardware side. There are also a number of issues to be solved to do with the way that Daedalus handles audio and display list processing.<br /><br />On the N64, the <a href="http://strmnnrmn.blogspot.com/2007/02/audio-support-in-daedalus-r9.html">audio and display lists</a> are processed asynchronously by the RSP coprocessor. In Daedalus, I can identify when these tasks are queued up for the RSP, intercept them, and process them synchronously (using high-level emulation rather than simulating the RSP execution directly). <br /><br />The key thing here is that as far as the emulated N64 is concerned, audio and display list processing currently happens instantaneously. As soon as it kicks off the RSP it gets a interrupt to inform it that processing has completed. The whole process is very deterministic and I'm worried that by processing these display lists asynchronously on the ME that a number of intermittent and hard-to-debug issues will crop up. On the other hand, processing these tasks asynchronously is much closer to the behaviour of a real N64, which may fix some timing-related issues. It will also allow Daedalus to exploit the inherent parallelism that N64 roms were designed to take advantage of.<br /><br />My current plan for ME audio support in R14 is:<br /><br /><ol><br /><li>Create a kernel mode PRX and get Daedalus successfully loading and invoking functions (under all supported firmwares). I've just about done this.<br /><li>Add the code to support initialising and running code on the ME to the PRX. Test invoking user mode functions from the main EBOOT.PBP. I'll probably be using J.F.'s <a href="http://forums.ps2dev.org/viewtopic.php?t=2652&postdays=0&postorder=asc&start=90">great sample code</a> as a reference for this. Thanks J.F.!<br /><li>Rewrite the audio list processing code so that it can be invoked synchronously or asynchronously as required (via some kind of configuration option). When running asynchronously it can just be run from a separate high-priority thread to start with. I can use this to test for various synchronisation issues without going through the pain of trying to do this on the ME first.<br /><li>Audit the audio list processing code to minimise any memory accesses or ensure that they are correctly synchronised with the main core/thread. Any crt or system calls need to be eliminated or abstracted away (e.g. printfs NOP when compiled to run on the ME).<br /><li>Invoke audio list processing code from the ME.<br /><li>Cross fingers.<br /></ol><br /><br />So, that's the plan; I'll keep you updated on my progress. If anyone has any experience doing this kind of thing on the ME it would be great to hear your thoughts.<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com29tag:blogger.com,1999:blog-13094505.post-91368986656037506062007-11-11T11:34:00.000+00:002007-11-11T11:41:06.744+00:00R13 Issues, R14 PlansOver the past week I've started making plans for what I want to do for R14.<br /><br />To start with, R13 introduced a couple of issues which I want to fix. Firstly, a number of roms now no longer work with dynarec enabled, or show odd behaviour. For instance, Aerogauge now finishes the race as soon as the countdown completes. I've tracked this down to one of the <a href="http://strmnnrmn.blogspot.com/2007/08/dynarec-improvements.html">dynarec optimisations</a> I added in August, where I optimise fragments which jump back to themselves. This should be a 'safe' transformation, so it suggests there's a bug somewhere in my implementation. If I can't fix the bug in time for R14, I'll add a temporary setting to allow this optimisation to be disabled on a rom-by-rom basis (much like the 'dynarec stack optimisation' setting).<br /><br />Secondly, it looks like something I changed for savestate support has broken the 'return to main menu' option. I added some logic to help ensure that when taking a snapshot for the savestate, the CPU is paused in a 'safe' state (i.e. no dynarec code is executing, nothing is running on the RSP, and nothing is executing in the branch delay slot.) It looks like I've messed something up which is causing the 'return to main menu' option to wait for a safe state before bailing out to the menu. Should be an easy one to fix.<br /><br /><a href="http://strmnnrmn.blogspot.com/2007/11/icons-for-daedalus.html#c926059453519439265">Morgan suggested a nice idea</a> in the comments, which is that I generate a thumbnail for the savestate as it is created to display alongside the slot in the UI. It's a little tricky to implement, as by the time the emulator is told to create a savestate, it has already obliterated the n64's framebuffer with the Daedalus UI. I'll have to do something quite clever like speculatively copy the n64's framebuffer into system memory every time you enter the Pause Menu, or create the screenshot on the first frame rendered after saving. Either way, I'd like to add this simple feature to R14.<br /><br />Next on my list for R14 is to look at making more significant performance improvements. Over the months <a href="http://www.google.co.uk/search?q=+site:strmnnrmn.blogspot.com+strmnnrmn+media+engine">many people have been asking</a> when I'd get around to implementing audio on the PSP's Media Engine. I've talked about this <a href="http://strmnnrmn.blogspot.com/2007/03/r10-plan-of-action.html">before</a>, but always kept putting it off in order to work on easier optimisations. <br /><br />The Media Engine is a bit of unknown territory for me. Even though it's practically identical to the main CPU, you can't just change a setting an suddenly have your code running on it. There are a number of small hurdles I have to overcome before I can get audio working on the ME, but this is my big goal for R14 (I'll save the technical discussion for the next post.) If all goes to plan this should mean that audio can always be enabled without a significant impact on framerate.<br /><br />So in summary for R14: a few bug fixes, thumbnails for savestates, and audio without affecting framerate.<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com29tag:blogger.com,1999:blog-13094505.post-22206953439486542742007-11-11T10:59:00.000+00:002007-11-11T11:21:56.716+00:00Firmware pollI'm interested in which firmware everyone is running on. It would be very helpful if you could reply to this post with a) which model of PSP you're using ('fat'/slim, revision # if known) and b) which firmware you're using.<br /><br />I have two PSPs. I have an original Japanese PSP with v1.00 firmware which I use for development, and a UK PSP which usually runs the latest official firmware (v3.72 at the moment.)<br /><br />I'm interested because I want to know if anyone still requires the v1.50 (kxploit) versions of Daedalus that I release. I also need to figure out if it's worth my time getting a slim PSP for developing with the v3.xx+ firmware.<br /><br />Thanks!<br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com124tag:blogger.com,1999:blog-13094505.post-12181163292676565442007-11-07T09:16:00.000+00:002007-11-07T09:26:27.454+00:00Icons update!Well it's only been a couple of days, but I've received over 50 submissions to date - It's going to take me some time to go through them! <br /><br />A couple of people have asked about the icon size. 134x74 or 140x80 are both fine.<br /><br />Thanks for all the entries so far - there have been some really great ones. Keep them coming!<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com15tag:blogger.com,1999:blog-13094505.post-21144517281670568622007-11-05T21:04:00.000+00:002007-11-05T21:29:01.851+00:00Icons for DaedalusI've never taken the time to add icons to the Daedalus EBOOT.PBP. Mostly it's just because I've been lazy (when I develop Daedalus I usually run it through psplink rather than the XMB, so I rarely see the frontend), but also because I've never found a suitable set of icons to use.<br /><br />There are plenty of <a href="http://www.riotsgraph.jp/pochistyle/">icon/background packs</a> floating around for Daedalus, but I've been reluctant to use any of them; I need something that I can freely distribute, but also something that doesn't infringe on any trademarks.<br /><br />I'd like to add icons and a background to Daedalus for the next release, so I'm opening a 'competition' to try and find the best design. The 'prize' will be full credit in the release notes and on the Daedalus About screen (including a link to your website if you wish). Here's what I'm looking for:<br /><br /><ul><br /><li>Background 480x272, preferably in .png format<br /><li>Icon 134*74, preferably in .png format<br /><li>No use of Nintendo's trademarks! This means no use of the <a href="http://en.wikipedia.org/wiki/Image:Nintendo_64_Logo.svg">"N64"</a> or <a href="http://en.wikipedia.org/wiki/Image:Nintendo.svg">"Nintendo"</a> logos. Sorry. Be inventive!<br /><li>You must own the work you submit, and give me permission to use it with Daedalus PSP<br /></ul><br /><br />Email your submissions to me (strmnnrmn@gmail.com). I'll post all the submissions I receive by <b>16th November</b> on this site to get people's thoughts, and make a decision the following Monday (19th November - that's two weeks today!)<br /><br />Of course if you don't like whatever decision I make, you're always welcome to repack the Daedalus EBOOT.PBP and use any of the other graphics people send in :)<br /><br />Time to get mspaint fired up!<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com29tag:blogger.com,1999:blog-13094505.post-87793946550575607512007-11-04T18:53:00.000+00:002007-11-04T22:34:09.947+00:00Daedalus PSP R13 ReleasedI've just finished packing up R13 and uploading it to sourceforge:<br /><br /><a href="http://downloads.sourceforge.net/daedalus-n64/daedalus_psp_R13_v100.zip">Daedalus PSP R13 for v1.00 Firmware</a><br /><a href="http://downloads.sourceforge.net/daedalus-n64/daedalus_psp_R13_v150.zip">Daedalus PSP R13 for v1.50+ Firmware</a><br /><a href="http://downloads.sourceforge.net/daedalus-n64/daedalus_psp_R13_src.zip">Daedalus PSP R13 Source</a><br /><br />The most significant new feature is savestate support. You can now save your progress at any point, via the Pause Menu (accessed through hitting the Select button). Savestates are written out to the memory stick, and consume around a megabyte per slot. You can load up a savestate at any time from the Pause Menu, or via the front end (hit the right shoulder button to swap from the rom list to the savestate list.)<br /><br />Other than savestates, the most significant change in R13 is a number of optimisations to the dynarec core which should give a 10-20% speedup depending on the title being played. I've tested these optimisations as much as I can, but if you find that roms which worked with R12 are now broken, try disabling 'dynamic recompilation' and/or 'dynarec stack optimisation' from the rom's preferences screen.<br /><br />I haven't looked at compatibility at all in R13, so it's unlikely that any roms will have started working in R13.<br /><br />I'm interested to hear your feedback on both of these features. Let me know if you have any problems with savestates, or if you've found roms are no longer working in R13. I'll try and keep on top of the comments pages over the next couple of weeks.<br /><br />It's taken a LOT longer to get R13 out than I had hoped. I can't quite believe the last release was in June! I'm hoping now I've got this release out of the door I'll be able to get back to making small, more frequent releases.<br /><br />-StrmnNrmn<br /><br /><b>Update</b> A couple of things have cropped up in the comments. Firstly, when you create a savestate it can take a while - up to 10 seconds - during which time the screen is black. It will complete though - please be patient :). I'll have a look at adding a progress meter or something like that for R14.<br /><br />There are a few titles that don't seem to be working well with some of the dynarec optimisations I added. If you're having problems, try turning off the 'dynarec stack optimisation' as discussed above.StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com148tag:blogger.com,1999:blog-13094505.post-48574166797798559992007-11-03T17:49:00.000+00:002007-11-03T17:56:47.564+00:00Daedalus R13 SoonI've just about finished implementing the last couple of <a href="http://strmnnrmn.blogspot.com/2007/10/r13-close-honestly.html">savestate features</a> I talked about last week.<br /><br />I've got a bit of polishing to do and a little bit more testing, but I'm hoping I should be able to release R13 sometime tomorrow (Sunday).<br /><br />I'll post again then with a complete list of changes and links to the latest builds for you to download. See you then!<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com29tag:blogger.com,1999:blog-13094505.post-16557509601491637082007-10-25T11:10:00.000+01:002007-10-25T11:39:26.859+01:00R13 close, honestly!Apologies again for the lack of updates. I know people get nervous when I don't update regularly, but I don't like to post when I have nothing new or exciting to talk about.<br /><br />I'm very close to releasing R13, I've just been struggling to find the time to add the final finishing touches to the savestate support. I've found it hard to get into a regular working pattern since moving, so what should have been a 1 week job has ended up taking a month. Bioshock and Halo 3 haven't helped either. <br /><br />Savestates are working very well. The current implementation provides 10 slots which are shared across all roms. You can save to any slot at any time from an option on the Pause menu, or choose to reload a previous savestate. In this way it works just like QuickSave/QuickLoad found in various PC games (I'm tempted to add a special slot for this to the top level of the Pause menu). <br /><br />I use zlib to compress the savestates, so an 8MiB savestate compresses down to 1MiB (or even smaller if you're running games which don't use the Expansion Pak).<br /><br />There are just a couple of things I need to finish off now before I can release. Firstly I need to check if the savestate you're loading is for a different rom than is currently loaded. If this is the case I need to scan through your available roms looking for the correct one, and load it. To make this efficient I need to get the RomDB which I use for the PC build working on the PSP.<br /><br />The second thing I need to do is come up with a decent way of linking some metadata to the savestate so I can show this in the UI. Just simple stuff like the full name of the rom, time the savestate was created and the total time spent playing when it was created. I figure without this information it'll be quite difficult to figure out what it stored in each savestate slot. The alternative is to add a text entry system to the UI so you can name each savestate, but I think this will just delay things even more.<br /><br />In summary R13 is really close and I've not forgotten about it. Just a few more things to sort out and it'll be ready for release.<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com37tag:blogger.com,1999:blog-13094505.post-30610806239417148402007-10-01T20:36:00.000+01:002007-10-01T21:28:55.431+01:00Daedalus and the PSP Slim + LiteA number of people have been asking if Daedalus will support the PSP Slim and Lite (PSP-2000), and if it does, if it will take advantage of the extra 32MiB RAM to improve the speed of emulated roms.<br /><br />I am planning on supporting 3.xx firmware, but not until I have a PSP with suitable firmware which I can test with directly. People will probably end up compiling the Daedalus source for 3.xx (and they're welcome to), but until I can verify everything directly myself these will have to remain 'unofficial' builds. If there is strong demand for a 3.xx version of Daedalus then I'll consider setting up a donations page with the aim of buying a Slim and Lite for development.<br /><br />As for the additional 32MiB RAM that the PSP-2000 provides, it's unlikely that this will provide for faster emulation. I've spent a lot of time reducing Daedalus's <a href="http://strmnnrmn.blogspot.com/2007/03/look-inside-daedalus.html">memory requirements</a> so that it runs comfortably in the 32MiB that the PSP-1000 provides (it's actually a fair bit less than this when you take out OS overheads etc.)<br /><br />There are only two main areas of the emulator that would benefit from an increase in cache size. The first is the texture cache, which is only used when video memory is exhausted. I fixed a few bugs with this months ago which means that very few roms ever have to place textures in system memory.<br /><br />The second place that would benefit from a cache increase is the ROM cache. In order to support roms larger than the PSP's system memory, I dyamically map pages of the ROM into the PSP's RAM on demand (rather like virtual memory on PCs.) If a page of the ROM that is requested isn't in the cache, I have to pause emulation as I load it from memory stick. Currently this cache size is 2MiB. It could be increased up to 32MiB which would fit most N64 roms comfortably, and would entirely eliminate paging while the emulator is running. This might give a small speedup, but I don't believe this is currently a significant issue even with the tiny 2MiB cache that is currently in use.<br /><br />Increasing the dynarec buffers would be very unlikely to provide a speedup, as I've yet to see a rom where they fill up before they are flushed for some other reason (typically instruction cache invalidation.)<br /><br />So in summary, yes, I will support the PSP Slim and Lite at some point, but no, it's unlikely to offer much of an improvement over the PSP-1000s (other than being slimmer and lighter, obviously :)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com6tag:blogger.com,1999:blog-13094505.post-69530842752639648452007-09-19T22:02:00.000+01:002007-09-19T22:37:11.278+01:00Back OnlineApologies for the lack of updates. I've not had internet access at home since moving flat at the end of August. My ADSL was activated today so I'm finally up and running again. I can't believe how long it's taken! <br /><br />Between the flat move and a busy few weeks at work (getting ready for the <a href="http://tgs.cesa.or.jp/english/">Tokyo Game Show</a>) I've not had that much time to work on Daedalus, but I have made some progress on a really cool feature people have been asking for for some time, namely savestate support.<br /><br />For those not familiar with <a href="http://en.wikipedia.org/wiki/Savestate">savestates</a>, the basic premise is very much like 'hibernate' or sleep modes on PCs and laptops. A savestate can be created at any point during emulation. At a later time the savestate can be reloaded to restore the emulator to the exact state it was in when the savestate was created.<br /><br />What's really useful about savestates is that they work even if the underlying save mechanism used by a rom isn't supported properly. I'm hoping that by adding savestate support Daedalus will become significantly more usable for many roms. Savestates also make development a lot easier as it means I can jump straight into the middle of a game when debugging/profiling rather than sitting through the title sequence dozens of times.<br /><br />I still have a little bit of work left to do on the savestate system, mostly on the UI side, but there are a number of additional optimisations I want to finish off before I release R13. I'm currently planning to get everything ready for release on either the weekend of the 29th Sept, or possibly the first weekend in October.<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com46tag:blogger.com,1999:blog-13094505.post-21771705601864004092007-08-15T23:13:00.000+01:002007-08-15T23:32:25.755+01:00WhoopsIt turns out that exophase had already suggested two of the three optimisations I implemented <a href="http://strmnnrmn.blogspot.com/2007/08/dynarec-improvements.html">this weekend</a> in a conversation we had <a href="http://strmnnrmn.blogspot.com/2007/08/dynarec-improvements.html#comment-5153123399030100085">way back in February</a>.<br /><br />Whoops! It's been such a long time, I'd totally forgotten we'd talked about it. I really should pay more attention sometimes - if I had been you might have seen some of these improvements way back in R9. Sorry exophase - kudos for spotting this so long ago!<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com9tag:blogger.com,1999:blog-13094505.post-59585337644836628512007-08-15T23:03:00.000+01:002007-08-15T23:03:58.935+01:00Interesting Dynarec HackI was playing around with the code generation a couple of evenings ago, and realised that if I made a certain assumption, I could drastically speed up specific types of memory accesses.<br /><br />When I discussed load/store handling <a href="http://strmnnrmn.blogspot.com/2007/08/dynarec-improvements.html">on Sunday</a>, I presented the new code that is typically generated for handling a load such as 'lw $t0, 0x24($t1)' on the N64:<br /><br /><pre><br /> ADDIU a0 = s1 + 0x0024 # add offset to base register<br /> SLT t0 = (a0<s6) # compare to upper limit<br /> BEQ t0 != r0 --> _Trampoline_XYZ123 # branch to trampoline if invalid<br /> ADDU a1 = a0 + s7 # add offset to emulated ram<br /> LW s0 <- 0x0000(a1) # load data<br /></pre><br /><br />(I'll ignore all the extra code which is generated, and just concentrate on the 5 instructions above which correspond to the expected path of execution.)<br /><br /> Of the 5 instructions that are generated, two - the SLT and BEQ - are just there for performing error handling in the case that the address is invalid, a hardware register (i.e. for <a href="http://en.wikipedia.org/wiki/Memory-mapped_IO">memory-mapped I/O</a>), or a virtual address. I'll call this error handling for short.<br /><br />If we were generating code in an idealised environment where we didn't have to perform error handling, we could drop the SLT/BEQ instructions to get this:<br /><br /><pre><br /> ADDIU a0 = s1 + 0x0024 # add offset to base register<br /> ADDU a1 = a0 + s7 # add offset to emulated ram<br /> LW s0 <- 0x0000(a1) # load data<br /></pre><br /><br />We could then optimise this even further and perform the offset calculation directly as a part of the LW instruction:<br /><br /><pre><br /> ADDU a1 = s1 + s7 # add offset to emulated ram<br /> LW s0 <- 0x0024(a1) # load data<br /></pre><br /><br />In this idealised situation we could reduce an emulated load to just two instructions, with no branches. That's a pretty good saving!<br /><br />The problem is that the environment we're generating code from is not 'ideal', and it's hard to know in advance of time which memory accesses are going to directly access physical ram, and which are going to access hardware registers or require virtual address translation. For that reason, we have to place a guard around every memory access to make sure that it behaves correctly. At least, that was the way I was thinking until earlier in the week.<br /><br />What I realised on Monday is that I can make an assumption that lets me remove the error handling code for certain types of load/stores. The assumption is that when the N64 accesses any memory through the stack pointer ($sp) register, the address is always going to be valid, physical memory.<br /><br />The assumption relies on the fact that most roms don't do anything particularly clever with their stack pointers - it gets set up for each thread to point at a valid region of memory then the game just runs along, pushing and popping values from it as the code executes. Of course, if the assumption is wrong then the emulator will just crash and grind to a halt in a unpredictable manner :)<br /><br />It was straightforward to add a hack to the code generation to exploit this kind of behaviour, and the results have been better than I expected - I'm seeing at least a 10% speed up, and the code expansion factor (the ratio of generated bytes of instructions to input bytes) has dropped from around 5.0x to 4.0x. Stability has been excellent too - I've run about 8 roms with the hack so far, and all of them have run perfectly.<br /><br />I think one of the reasons the hack has such an impact is that a lot of the memory accesses in a typical C program are through the stack. Here's an example snippet from the entry to a function on the N64, where the compiler emitted code to store the return address and arguments:<br /><br /><pre><br />SW ra -> 0x0014(sp)<br />SW a0 -> 0x0058(sp)<br />SW a1 -> 0x005c(sp)<br />SW a2 -> 0x0060(sp)<br /></pre><br /><br />When I look through disassembly for the roms I'm working on, it's very common to see lots of sequential loads/stores relative to the stack pointer like this.<br /><br />Previously Daedalus generated around 20 instructions (including 5 branches) for the above snippet. With the hack, the generated code now looks like this:<br /><br /><pre><br />ADDU t1 = s1 + s7<br />SW s4 -> 0x0014(t1)<br />ADDU t1 = s1 + s7<br />SW s3 -> 0x0058(t1)<br />ADDU t1 = s1 + s7<br />SW s2 -> 0x005c(t1)<br />ADDU t1 = s1 + s7<br />SW s5 -> 0x0060(t1)<br /></pre><br /><br />8 instructions, 0 branches. What's more, it looks like with a little work, I could eliminate 3 redundant address calculations:<br /><br /><pre><br />ADDU t1 = s1 + s7<br />SW s4 -> 0x0014(t1)<br />SW s3 -> 0x0058(t1)<br />SW s2 -> 0x005c(t1)<br />SW s5 -> 0x0060(t1)<br /></pre><br /><br />Now that would be efficient :)<br /><br />I still want to do lots of testing with the hack. I want to find out if there are roms that don't work with the hack enabled, and how common a problem it is. It's such a significant optimisation though that I'm certain I'll be adding it as an option in Daedalus R13. The results of my testing will probably determine whether I default it to on or off though.<br /><br />So far Daedalus R13 is shaping up to be significantly faster than R12. I'm still not sure when I'll be ready to release it, but you'll hear about it here first.<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com17tag:blogger.com,1999:blog-13094505.post-91156711779346726762007-08-13T00:01:00.000+01:002007-08-13T00:06:16.885+01:00Dynarec ImprovementsI've had a fairly productive week working on optimising the Dynarec Engine. It's been a few months since I worked on improving the code generation (as opposed to <a href="http://strmnnrmn.blogspot.com/2007/06/super-smash-bros-dynarec-update.html">simply</a> <a href="http://strmnnrmn.blogspot.com/2007/06/tracking-down-ssb-dynarec-bug.html">fixing</a> <a href="http://strmnnrmn.blogspot.com/2007/06/tracking-down-ssb-dynarec-bug-part-2.html">bugs</a>), so it's taken me a while to get back up to speed.<br /><br />At the end of each fragment, I perform a little housekeeping to check whether it's necessary to exit from the dynarec system to handle various events. For instance, if a vertical blank is due this can result in me calling out to the graphics code to flip the current display buffers. The check simply involves updating the N64's COUNT register, and checking to see whether there are any time-dependent interrupts to process (namely vertical blank or COMPARE interrupts.) <br /><br />I had an idea on the train into work on Monday I realised that there were a couple of ways in which I could make this more efficient. Firstly, the mechanism I was using to keep track of pending events was relatively complex, involving maintaining doublely-linked lists of events. I realised that if I simplified this code it would make it much easier for the dynarec engine to update and check this structure directly rather than calling out to C code. <br /><br />The other idea I had on the train was to split up the function I was calling to do this testing into two different versions. There are two ways that the dynarec engine can be exited - either through a normal instruction, or a branch delay instruction (i.e. an instruction immediately following a branch.) My handler function catered for both of these cases by taking a flag as an argument. I realised that by providing a separate version of this function for each type I could remove the need to pass this flag as an argument, which saved a couple of instructions from the epilogue of each fragment.<br /><br />These two small changes only took a couple of hours to implement, but yielded a 3-5% speedup on the various roms I tested. They also slightly reduced the amount of memory needed for the dynarec system, improving cache usage along the way.<br /><br />The next significant optimisation I made this week was to improve the way I was handling the code generation for load/stores. Here's what the generated code for 'lw $t0, 0x24($t1)' looks like in Daedalus R12 (assume t1 is cached in s1, and t0 is cached in s0 on the PSP):<br /><br /><pre><br /> ADDIU a0 = s1 + 0x0024 # add offset to base register<br /> SLT t0 = (a0<s6) # compare to upper limit<br /> ADDU a1 = a0 + s7 # add offset to emulated ram<br /> BNEL t0 != r0 --> cont # valid address?<br /> LW s0 <- 0x0000(a1) # load data<br /> J _HandleLoadStore_XYZ123 # handle vmem, illegal access etc<br /> NOP<br />cont:<br /> # s0 now holds the loaded value,<br /> # or we've exited from dynarec with an exception<br /></pre><br /><br />There are a couple of things to note here. Firstly, I use s6 and s7 on the PSP to hold two constants throughout execution. s6 is either 0x80400000 or 0x80800000 depending on whether the N64 being emulated has the Expansion Pak installed. s7 is set to be (emulated_ram_base - 0x80000000). Keeping these values in registers prevents me from using them for caching N64 registers, but the cost is far outweighed by the more streamlined code. As it happens, I also use s8 to hold the base pointer for most of the N64 CPU state (registers, pc, branch delay flag etc) for the same reason.<br /><br />So the code first adds on the required offset. It then checks that the resulting address is in the range 0x80000000..0x80400000, and sets t0 to 1 if this is the case, or clears it otherwise*. It then adds on the offset (emulated_ram_base - 0x80000000) which gives it the translated address on the psp in a1. The use of BNEL 'Branch Not Equal Likely' is carefully chosen - the 'Likely' bit means that the following instruction is only executed if the branch is taken. If I had used a plain 'BNE', the emulator could often crash dereferencing memory with the following LW 'Load Word'.<br /><br />Assuming the address is out of range, the branch and load are skipped, and control is passed to a specially constructed handler function. I've called it _HandleLoadStore_XYZ123 for the benefit of discussion, but the name isn't actually generated, it's just meant to indicate that it's unique for this memory access. The handler function is too complex to describe here, but it's sufficient to say that it returns control to the label 'cont' if the memory access was performed ok (e.g. it might have been a virtual address), else it bails out of the dynarec engine and triggers an exception.<br /><br />When I originally wrote the above code I didn't think it was possible to improve it any further. I didn't like the J/NOP pair, but I saw them as a necessary evil. All 'off trace' code is generated in a second dynarec buffer which is about 3MiB from the primary buffer - too far for a branch which has a maximum range of +/-128KiB. I used the BNEL to skip past the Jump 'J' instruction which can transfer control anywhere in memory. <br /><br />What I realised over the weekend was that I could place a 'trampoline' with a jump to the handler function immediately following the code for the fragment. Fragments tend to be relatively short - short enough to be within the range of a branch instruction. With this in mind, I rewrote the code generation for load and store instructions to remove the J/NOP pair from the main flow of the trace:<br /><br /><pre><br /> ADDIU a0 = s1 + 0x0024 # add offset to base register<br /> SLT t0 = (a0<s6) # compare to upper limit<br /> BEQ t0 != r0 --> _Trampoline_XYZ123 # branch to trampoline if invalid<br /> ADDU a1 = a0 + s7 # add offset to emulated ram<br /> LW s0 <- 0x0000(a1) # load data<br />cont:<br /> # s0 now holds the loaded value,<br /> # or we've exited from dynarec with an exception<br /> #<br /> # rest of fragment code follows<br /> # ...<br /> <br /> <br />_Trampoline_XYZ123:<br /> # handler returns control to 'cont'<br /> J _HandleLoadStore_XYZ123 <br /> NOP<br /></pre><br /><br />The end result is that this removes two instructions from the main path through the fragment. Although in the common case five instructions are executed in both snippets of code, the second example is much more instruction cache friendly as the 'cold' J/NOP instructions are moved to the end of the fragment. I've heard that there is a performance penalty for branch-likely instructions on modern MIPS implementations, so it's nice to get rid of the BNEL too.<br /><br />As with the first optimisation, this change yielded a further 3-5% speedup.<br /><br />The final optimisation I've made this weekend is to improve the way I deal with fragments that loop back to themselves as they exit. Here's a simple example:<br /><br /><pre><br /><b>8018e014</b> LB t8 <- 0x0000(a1)<br />8018e018 LB t9 <- 0x0000(a0)<br />8018e01c ADDIU a0 = a0 + 0x0001<br />8018e020 XOR a2 = t8 ^ t9<br />8018e024 SLTU a2 = (r0<a2)<br />8018e028 BEQ a2 == r0 --> 0x8018e038<br />8018e02c ADDIU a1 = a1 + 0x0001<br />8018e038 LB t0 <- 0x0000(a0)<br />8018e03c NOP<br />8018e040 BEQ t0 == r0 --> 0x8018e058<br />8018e044 NOP<br />8018e048 LB t1 <- 0x0000(a1)<br />8018e04c NOP<br />8018e050 BNE t1 != r0 --> <b>0x8018e014</b><br />8018e054 NOP<br /></pre><br /><br />I'm not sure exactly what this code is doing - it looks like a loop implementing something like strcmp() - but it's one of the most executed fragments of code in the front end of <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtzX_XmAi2kekXC6ZqKMxfT7nIntcEGtJRWr46KPnMldvLECxmDymxmj_JZfUwVWUUEkQH2to7J9vneu6o-OOBFpufaGchdvv4dc3fKt7OrAv5HkOC_52YypPxN27vnPXO6mJWMQ/s1600-h/SuperMario64_a.png">Mario 64</a>.<br /><br />The key thing to notice about this fragment is that the last branch target loops back to the first instruction. In R12, I don't perform any specific optimisation for this scenario, so I flush any dirty registers that have been cached as I exit, and immediately reload them when I re-enter the fragment. Simplified pseudo-assembly for R12 looks something like this:<br /><br /><pre><br />enter_8018e014:<br /> <i>load n64 registers into cached regs</i><br /> <br /> perform various calculations on cached regs<br /> <br /> if some-condition<br /> flush dirty cached regs back to n64 regs<br /> goto enter_8018e038<br /> <br /> perform various calculations on cached regs<br /> <br /> <i>flush dirty cached regs back to n64 regs</i><br /> <br /> if ok-to-continue<br /> goto enter_8018e014<br />exit_8018e014:<br /> ...<br /> <br />enter_8018e038:<br /> ...<br /></pre><br /><br />The key thing to notice is that we load and flush the cached registers on every iteration through the loop. Ideally we'd just load them once, loop as much as possible, and then flush them back to memory before exiting. I've spent the day re-working the way the dynamic recompiler handles situations such as this. This is what the current code looks like:<br /><br /><pre><br />enter_8018e014:<br /> <i>load n64 registers into cached regs</i><br /> <b>mark modified regs as dirty</b><br /><br />loop: <br /> perform various calculations on cached regs<br /> <br /> if some-condition<br /> flush dirty cached regs back to n64 regs<br /> goto enter_8018e038<br /> <br /> perform various calculations on cached regs<br /> <br /> if ok-to-continue<br /> goto loop<br /><br /> <i>flush dirty cached regs back to n64 regs</i><br />exit_8018e014:<br /> ...<br /> <br />enter_8018e038:<br /> ...<br /></pre><br /><br />In this version, the registers are loaded and stored outside of the inner loop. They may still be flushed during the loop, but only if we branch to another trace. Before we enter the inner loop, we need to mark all the cached registers as being dirty, so that they're correctly flushed whenever we finally exit the loop.<br /><br />This new method is much more efficient when it comes to handling tight-inner loops such as the assembly shown above. I still have some work to do in improving my register allocation, but the changes I've made today yield a 5-6% speedup. Combined with the other two optimisations I've described, I'm currently seeing an overall 10-15% speedup over R12. <br /><br />I'm quite excited about the progress I've made so far with R13. I still have lots of ideas for other optimisations I want to implement for R13 which I'll talk about over the coming days. I don't have any release date in mind for R13 at the moment, so there's no point in asking me yet :)<br /><br />-StrmnNrmn<br /><br /><br />*The SLT instruction is essentially doing 'bool inrange = address >= 0x80000000 && address < (0x80000000+ramsize)'. I think the fact that this can be expressed in a single instruction is both beautiful and extremely fortunate :)StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com28tag:blogger.com,1999:blog-13094505.post-69572716414438716362007-08-02T23:58:00.000+01:002007-08-03T00:18:24.813+01:00Daedalus PSP under OSXI mentioned a few days ago that I've recently bought a <a href="http://strmnnrmn.blogspot.com/2007/07/recharged.html">Macbook Pro</a>. I've never owned a Mac before so it's been a really interesting experience learning my way around. Initially I was planing on dual booting Windows XP via <a href="http://www.apple.com/macosx/bootcamp/">Boot Camp</a>, but I quickly found that I could do almost everything I need to in OSX. I did install <a href="http://www.parallels.com/products/desktop/">Parallels Desktop</a>, I rarely find myself running any Windows apps.<br /><br />One of the main things I need for day to day 'work' is the ability to compile and run Daedalus. The rest of this article describes the process of setting up the PSPSDK under OSX, and compiling Daedalus PSP for the first time. This post is really aimed at people who are interested in compiling Daedalus for themselves on OSX. Hopefully it will also be useful for other PSP homebrew developers who have been having problems getting the PSPSDK set up under OSX.<br /><br />To install the PSPSDK I largely followed <a href="http://forums.ps2dev.org/viewtopic.php?t=5391">this guide</a> on the ps2dev.org forums. I already had XCode and fink installed. Fink complained when I tried to install all the listed packages, and I had to remove one of them from the command line (I <i>think</i> it was autogen, but I can't really remember now.)<br /><br />I've been using the most recent psptoolchain script, which was updated a few weeks ago, and I had to make a couple of modifications. In depends/check-ncurses.sh I had to change the check for ncurses to look for the OSX .dyliib file:<br /><br /><pre><br />## Check for a ncurses library.<br />ls /usr/lib/libncurses.a 1> /dev/null ||<br /> ls /usr/lib/libncurses.dll.a ||<br /> { echo "ERROR: Install ncurses before continuing."; exit 1; }<br /></pre><br /><br />became:<br /><br /><pre><br />## Check for a ncurses library.<br />ls /usr/lib/libncurses.a 1> /dev/null ||<br /> ls /usr/lib/libncurses.dll.a ||<br /> ls /usr/lib/libncurses.dylib ||<br /> { echo "ERROR: Install ncurses before continuing."; exit 1; }<br /></pre><br /><br />Secondly I had to make this change to scripts/001-binutils-2.16.1.sh. As <b>urchin</b> mentions on the ps2dev.org forum, ".m" is the extension for Objective C files in OSX. The '-r' tells <i>make</i> to ignore the built-in implicit rules, and everything works fine:<br /><br />So:<br /><br /><pre><br />## Compile and install.<br />make clean && make -j 2 && make install && make clean || { exit 1; }<br /></pre><br /><br />became:<br /><br /><pre><br />## Compile and install.<br />make clean && make -r -j 2 && make install && make clean || { exit 1; }<br /></pre><br /><br />(note the '-r' flag on the second invocation of make.)<br /><br />I left the psptoolchain script doing its stuff for a couple of hours, and when I came back to it everything seemed to have completed and installed correctly. <br /><br />The next step was to get Daedalus PSP compiling. Somewhat naively I assumed Daedalus PSP would compile out of the box on OSX. As it turns out, I had to make a few small changes to get everything compiling nicely.<br /><br />Firstly, I had to update the makefile so that it directly referenced psp-gcc and psp-g++. Normally, I build Daedalus PSP through a Visual Studio Makefile project, and I had used a couple of scripts from the ps2dev.org forums to format GCC's output into a format that Visual Studio understands, so that double clicking on an error in the output opens the corresponding file in the editor. I found a <a href="http://forums.ps2dev.org/viewtopic.php?p=21849#21849">better way</a> to handle this, so I changed the CC/CXX macros to refer to the original pspsdk tools.<br /><br />The main problem I encountered was my arbitrary use of backslashes instead of forward slashes in #include directives, e.g.:<br /><br /><pre><br />#include "Core\CPU.h"<br /></pre><br /><br />should be:<br /><br /><pre><br />#include "Core/CPU.h"<br /></pre><br /><br />Another subtle error came from the way that I was instantiating static functions from templated classes which are defined in a namespace. An example will probably help explain. Here's the basic outline of the class I use to implement the singleton pattern:<br /><br /><pre><br />namespace daedalus<br />{<br /> template< class T><br /> class CSingleton<br /> {<br /> public:<br /> static bool Create();<br /><br /> static T * Get() { return mpInstance; }<br /><br /> private:<br /> T * mpInstance;<br /> };<br />}<br /></pre><br /><br />The Create method for the singleton class is then implemented like this:<br /><br /><pre><br />template<> bool CSingleton< CController >::Create()<br />{<br /> DAEDALUS_ASSERT_Q(mpInstance == NULL);<br /> <br /> mpInstance = new IController();<br /><br /> return true;<br />}<br /></pre><br /><br />For some reason this started failing when compiling Daedalus PSP under OSX:<br /><br /><pre><br />Source/Core/PIF.cpp: At global scope:<br />Source/Core/PIF.cpp:250: error: specialization of 'static bool<br /> daedalus::CSingleton<T>::Create() [with T = CController]' in different namespace<br />Source/Core/PIF.cpp:250: error: from definition of 'static bool<br /> daedalus::CSingleton<T>::Create() [with T = CController]'<br /></pre><br /><br />Rather than being an OSX issue, I suspect that the reason this error started occurring was actually due to the PSPSDK using an updated version of GCC which is a bit stricter than the version I was using on Windows. Regardless, the fix was easy - the code just needed to be wrapped in the 'daedalus' namespace:<br /><br /><pre><br />namespace daedalus<br />{<br />template<> bool CSingleton< CController >::Create()<br />{<br /> DAEDALUS_ASSERT_Q(mpInstance == NULL);<br /> <br /> mpInstance = new IController();<br /><br /> return true;<br />}<br />}<br /></pre><br /><br />(I've recently been going off the singleton pattern, but that's <a href="http://c2.com/cgi/wiki?search=Singleton">another story</a> :)<br /><br />With these changes Daedalus PSP compiles perfectly under OSX. On my 2.4 GHz Macbook Pro it takes just under 50 seconds. On my 2.4GHz Windows machine it takes over 2 minutes to compile, so I'm very impressed with the results.<br /><br />I believe I've checked in all the required changes to the Daedalus SVN repository on SourceForge. If you decide to try compiling Daedalus PSP under OSX, let me know how you get on via the comments page (I'll be rejecting any off-topic comments to try and keep the discussion constructive)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com12tag:blogger.com,1999:blog-13094505.post-17669255025079733262007-08-01T00:15:00.000+01:002007-08-01T00:19:15.297+01:00333 MHzOn startup Daedalus increases the default <a href="http://forums.ps2dev.org/viewtopic.php?p=52329">clock frequency</a> of the PSP's cpu from 222MHz to 333MHz for a 'free' 50% speedup. I use 'free' in quotes because this comes at the expense of drawing more power so the battery runs out of charge faster.<br /><br />I've been asked if I'm going to support 333MHz many times, so I wanted to put this question to rest for once and for all. The answer is yes - I believe this has been the case since R1 :)<br /><br />-StrmnNrmnStrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com12tag:blogger.com,1999:blog-13094505.post-71590993853230182702007-07-30T23:45:00.000+01:002007-07-31T08:39:10.338+01:00Custom Controller ConfigurationsA number of people have asked if I would be adding support for user-defined controller configurations in a future release of Daedalus. As it happens Daedalus has supported user-defined controller configurations from R7 onwards. From the readme file:<br /><br /><blockquote><br />As of R7 Daedalus now allows user-configurable controls to be specified.<br />The desired controls can be chosen from the Rom Settings screen.<br /><br />In order to define your own controller configuration you need to add a <br />new .ini file to the Daedalus/ControllerConfigs directory. There are a<br />few examples provided which should give an overview of what is possible.<br />I will look at providing a more thorough tutorial shortly.</blockquote><br /><br />The format really is quite simple, but it is very flexible and allows for a number of advanced configurations. Here is a simple configuration which is distributed with Daedalus (ControllerConfigs/dpad.ini):<br /><br /><blockquote><br />Name=DPad<br />Description=By default the PSP DPad maps to the N64 DPad. Hold Circle to map to the CButtons.<br /><br />[Buttons]<br />N64.Start = PSP.Start<br />N64.A = PSP.Cross<br />N64.B = PSP.Square<br />N64.Z = PSP.Triangle<br />N64.LTrigger = PSP.LTrigger<br />N64.RTrigger = PSP.RTrigger<br />N64.Up = !PSP.Circle & PSP.Up<br />N64.Down = !PSP.Circle & PSP.Down<br />N64.Left = !PSP.Circle & PSP.Left<br />N64.Right = !PSP.Circle & PSP.Right<br />N64.CUp = PSP.Circle & PSP.Up<br />N64.CDown = PSP.Circle & PSP.Down<br />N64.CLeft = PSP.Circle & PSP.Left<br />N64.CRight = PSP.Circle & PSP.Right<br /></blockquote><br /><br />The file starts with two lines defining the name and description for the controller config. These strings are used in the UI when selecting configurations. The '[Buttons]' block defines the mapping from PSP controls to N64 controls. In this particular configuration the N64 d-pad is mapped to the PSP d-pad when the circle button is released. When circle is pressed, the PSP d-pad maps to the N64 c-buttons. This config is particularly useful for games which make heavy use of the d-pad.<br /><br />In the [Buttons] section, the left hand side of each rule must consist of one of the following N64 control names:<br /><br /><br /><table><br /><tr><th>Name</th><th>Description</th></tr><br /><tr><td>N64.Start</td><td>The N64's start button</td></tr><br /><tr><td>N64.A</td><td>The N64's A button</td></tr><br /><tr><td>N64.B</td><td>The N64's B button</td></tr><br /><tr><td>N64.Z</td><td>The N64's Z trigger</td></tr><br /><tr><td>N64.LTrigger</td><td>The left trigger</td></tr><br /><tr><td>N64.RTrigger</td><td>The right trigger</td></tr><br /><tr><td>N64.Up</td><td>Up on the N64's d-pad</td></tr><br /><tr><td>N64.Down</td><td>Down on the N64's d-pad</td></tr><br /><tr><td>N64.Left</td><td>Left on the N64's d-pad</td></tr><br /><tr><td>N64.Right</td><td>Right on the N64's d-pad</td></tr><br /><tr><td>N64.CUp</td><td>The N64's C up button</td></tr><br /><tr><td>N64.CDown</td><td>The N64's C down button</td></tr><br /><tr><td>N64.CLeft</td><td>The N64's C left button</td></tr><br /><tr><td>N64.CRight</td><td>The N64's C right button</td></tr><br /></table><br /><br />N.B. There is currently no definition for the N64's analogue stick. By default this is always assumed to be bound to the PSP's analogue stick.<br /><br />The right hand side of a rule consists of an expression defined from the following values:<br /><br /><table><br /><tr><th>Name</th><th>Description</th></tr><br /><tr><td>PSP.Start</td><td>The PSP's start button</td></tr><br /><tr><td>PSP.Cross</td><td>The PSP's cross button</td></tr><br /><tr><td>PSP.Square</td><td>The PSP's square button</td></tr><br /><tr><td>PSP.Triangle</td><td>The PSP's triangle button</td></tr><br /><tr><td>PSP.Circle</td><td>The PSP's circle button</td></tr><br /><tr><td>PSP.LTrigger</td><td>The PSP's left shoulder button</td></tr><br /><tr><td>PSP.RTrigger</td><td>The PSP's right shoulder button</td></tr><br /><tr><td>PSP.Up</td><td>Up on the PSP's d-pad</td></tr><br /><tr><td>PSP.Down</td><td>Down on the PSP's d-pad</td></tr><br /><tr><td>PSP.Left</td><td>Left on the PSP's d-pad</td></tr><br /><tr><td>PSP.Right</td><td>Right on the PSP's d-pad</td></tr><br /></table><br /><br />N.B. You cannot use the PSP's select button when defining controller configurations, as this is reserved for the emulator's use.<br /><br />Values can be combined using a few simple operations to allow rules to be constructed with more complex behaviour. For instance, the following line:<br /><br /><pre>N64.CUp = PSP.Circle & PSP.Up</pre><br /><br />Tells Daedalus to report that the N64 C up button is pressed when both the circle AND d-pad up buttons are pressed on the PSP. The NOT operator (!) can be used to invert a value, for instance:<br /><br /><pre>N64.Up = !PSP.Circle & PSP.Up</pre><br /><br />This rule tells Daedalus to report that the N64 d-pad up button is pressed when the PSP's circle button is not pressed while the d-pad up button is being pressed.<br /><br />The available logical operators are:<br /><br /><table><br /><tr><th>Operator</th><th>Description</th><th>Example</th></tr><br /><tr><td>expr & expr</td><td>Returns the logical AND of the two expressions</td><td>N64.CUp=PSP.LTrigger & PSP.Up</td></tr><br /><tr><td>expr | expr</td><td>Returns the logical OR of the two expressions</td><td>N64.A=PSP.Cross | PSP.Circle</td></tr><br /><tr><td>!expr</td><td>Returns the logical NOT of the expression</td><td>N64.Up = !PSP.LTrigger & PSP.Up</td></tr><br /></table><br /><br />You can also use parentheses to control the order of precedence, e.g.:<br /><br /><pre>N64.CUp = PSP.Up | (PSP.LTrigger & PSP.Triangle)</pre><br /><br />Which defines a rule which defines that the N64 C up button is pressed when either up on the PSP d-pad is pressed, or when the left shoulder button and triangle are pressed.<br /><br />No single controller mapping scheme can be provided which works well across all games, but using custom controller configs it should be possible to create a mapping which works well for any given game.<br /><br />Post any questions you might have in the comment pages, and I'll do my best to answer them. If you come up with a good controller config for a game, email me (my name @gmail.com) and I'll look at adding it for distribution with future releases of Daedalus.<br /><br />-StrmnNrmn<br /><br />(Apologies - for some reason my template in Blogger really screws up when I place tables in he post and inserts a ton of whitespace before the table. I've never quite figured out how to fix it, so we'll just have to live with it :)<br /><br />(Fixed post date :)StrmnNrmnhttp://www.blogger.com/profile/03600572834319980086noreply@blogger.com9