Salut!!
Strum nous laisse deux message.
edit:il a encore laisser 2 nouveau message :je suis en train de les traduire
Premier consernant la r14
Sunday, November 11, 2007
R13 Issues, R14 Plans
Over the past week I've started making plans for what I want to do for R14.
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 dynarec optimisations 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).
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.
Morgan suggested a nice idea 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.
Next on my list for R14 is to look at making more significant performance improvements. Over the months many people have been asking when I'd get around to implementing audio on the PSP's Media Engine. I've talked about this before, but always kept putting it off in order to work on easier optimisations.
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.
So in summary for R14: a few bug fixes, thumbnails for savestates, and audio
traduction par moi :
"En cette fin de semaine j'ai commencé à penser ce que je voudrais pour la r14 : pour commencer la r13 a introduit des éléments que je veux fixer : premièrement certaine roms plante rapidement avec le dynarec activer ou son moins rapide (zelda mm et goldeneye) Aerogauge affiche un time up dés le commencement de la course. J'ai voulus l'enlever en désactivent le dynarec optimisation que j'ai ajouté en aout ou j'optimise des fragments du programme mais il i a une transformation de sécurité donc je pense qu'il i a un bug quelle que par dans l'implantation du programme : si je ne peux le fixer pour la r14, j’ajouterais une option temporairement pour éviter le problème (qui sera mieux que l'option dynarec stack)
"Deuxièmement on dirais que quelque chose que j'ai changer pour le support des savedata a casser l'option de retour au menu (un problème de dynarec qui fait que lorsque on fait pose le code s'arrête et empêche le lancement de l'option retour au menu)mais ce sera très facile a fixer"
Morgan (des commentaires de son site)ma suggérer une bonne ides dans les commentaire : générer un thumbnail pour les savestates .Ca prend quelque ligne a programmer et ca va tous de suite aider le framebuffer de la n64 avec le daedalus UI .Je veux faire quelque chose comme la copie spéculatives( ??)du n64 framebuffer dans le système a chaque fois que l’on rentre dans le menu pause ou créé un screenshot sur la première image a l’écran après la sauvegarde. J’aimerais intégrer se simple protocole dans la r14.
Ensuite sur ma liste pour Daedalus je voudrais faire une signifiante avancer sur la vitesse .Dans les dernier moi plein de personne on demander quand je vais implanter l’audio sur le PSP Media Engine .Je voulais le fer depuis longtemps mais je ne l’ai jamais fait car j’étais concentrer sur de petite optimisation .Le Media Engine est un peut un terrain inconnu pour moi. C’est pratiquement identique aux Main CPU, tu ne peux changer une option sans que ton code ne marche plus. Il y a beaucoup de petite chose que je doit faire pour faire fonctionner l’audio sur le media engine mais c’est mon grand but pour la R14 (J’ai sauvegarder la discutions technique de mon prochaine post).Si tous se passe comme j’ai prevu,on pourra utiliser l’audio sans conséquences significative sur la vitesse .En gros: des bug fixer, des screenshot pour les savestates et l’audio sans contraintes significatives sur la vitesse."
Firmware poll
I'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.
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.)
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.
Thanks!
-StrmnNrmn
traduc par moi:
Je suis interesser sur quelle firmware vous utiliser Daedalus.Je serais revis que vous repondier (sur le forum de son sit avec compte google requis)
a)Quel model(fat/slim )
b)Quel firware vous utiliser
J’ai deux PSP.Une fat Japonaise avec le 1.00 avec laquelle je programme,et une englaise avec la derniere version officialle (3.72 en ce moment).Je suis interaisser de savoir parce que je veut savoir si quelqu’il a besoin de la version 1.5(kxploit) de Daedalus que je release.J’ai besoin de savoir si il est temps de prendre une psp slim pour developer en 3.XX
Merci !
-StrmnNrmn
Faites Moi savoir par MP les reponse que je doit envoiller a strum si vous n’aver pas de comptes google
(EDIT) les 2 nouveau message(que je suis en train de traduire!!)
Icons update (part 2)!
..And the last update today (I promise!)
I just wanted to say that I've now received about 100 entries for the icon competition. I'm about halfway through the list so far; apologies if I've not responded to your entry yet.
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.
I've had lots of entries from readers of PSP-Generation, so a big 'merci beaucoup' for that. It's certainly helping exercise my rusty French
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!
-StrmnNrmn
PS Remember it's 'daedalus' and not 'deadalus'. It's an easy mistake to make
Deuxième partie sur les icones et dernier post pour aujourd’hui (ouf Mar de taper ,je pense que je vais racoursir les derniere parti)
Je veux juste dire que j’ai reçu plus de 100 entrer pour la compétition sur les icones mais je n’ai vu que la moitié pour l’instant donc je n’ai pas pus répondre a tous les e-mails. Au début je voulais présenter tous les icône pour que tous le monde puisse choisir mais il y a trop d’entrer alors le week-end prochain je présenterais les 10 que je préfère .J’ai beaucoup d’entrer de la part des liseur de PSP-Générations(On représente lol)alors un grand « merci beaucoup » a eux .Ca va certainement aider mon français qui est sûrement enrouiller. Il ne reste plus que 1 semaines avant la fin de la compétition .Rappeler vous que c’est Daedalus et pas Daedalus.
Media Engine
Earlier I discussed my plans for getting Daedalus's audio processing working on the PSP's Media Engine.
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.
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 think kernel mode rules out anyone running with v1.50 firmware (hence my earlier post - 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.
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.
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.
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.
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.
On the N64, the audio and display lists 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).
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.
My current plan for ME audio support in R14 is:
1. Create a kernel mode PRX and get Daedalus successfully loading and invoking functions (under all supported firmwares). I've just about done this.
2. 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 great sample code as a reference for this. Thanks J.F.!
3. 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.
4. 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).
5. Invoke audio list processing code from the ME.
6. Cross fingers.
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.
-StrmnNrmn
Derniere Nouvelle
Media Engine progress
Over the weekend I described my plans 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 kernel mode PRX to handle the ME nitty gritty, and I've managed to execute some test code on the ME successfully.
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.
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
Voila deso pas de traduc sur les deux derniers
