Monday, June 05, 2006

Source updated

Earlier this evening I updated the project CVS repository with the latest version of the code. Normally I only do this when I release a new build, but I know people have been playing with the code and have expressed an interest in seeing the latest developments.

I'm not quite ready to release a new binary yet (still a few more optimisations I want to make and various bugs to fix first), but I'll try and do this within the coming week.

Incidentally, updating the source normally only takes 20 minutes or so, but it took a good couple of hours tonight. Sourceforge updated their CVS service recently (May 12th) and as a result I had to spend a couple of hours updating WinCVS, generating new SSH keys and the like. Hopefully it won't be so painful next time around, or I might just lose the will to live.

As a more general update, I cleared a couple of things from my TODO list sorted this weekend. I'm caching floating point registers for most of the single-precision Cop1 instructions, which are now implemented directly in the dynarec code. I've not timed this in depth yet, but it's shaving 10-20ms/frame off the intro to Mario 64 (Mario's Head), which is particularly FPU heavy (i.e. I'm getting ~160ms/frame rather than ~180ms)

Finally I need to have a good think about how to go about optimising the double-precision floating point performance. As the PSP doesn't have hardware support for double precision floating point this is currently very expensive (i.e. adding 2 doubles on the n64 takes just one instruction - on the psp this balloons to several hundred as it all has to be done in software).

Currently I cheat and cast all the double-precision floats to single-precision values before performing the calculations. Although this is much faster it obviously loses a lot of precision, so I need to be careful it's not going to break any roms. Also even the float->double/double->float conversions are pretty expensive so it's still not an ideal solution. Fortunately not many roms seem to use double-precision maths extensively (presumably because it was relatively expensive on the n64), and where they do use it they don't seem to be too sensitive to the fact that I'm throwing most of their mantissa away :)


narles said...

Excellent work! Thanks for the update. The part about the double-precision floating point performance was interesting to read about. I hope that you are able to work it out in a way that you find satisfactory. Keep up the good work!

PSDroideka said...

This is going to be good! :P

Kramer said...

cool can someone compile this for me and send it to my email please
id do it myself if i knew how to

PSDroideka said...

Me again, just one last question, will an expansion pack option be enabled soon? In PC emulators its normally a case of increasing the RDRAM but i suppose the psp would be different.....

kersplatty said...

how can i download the source? good luck in your work

kekpsp said...

Can someone post a compiled version of the latest source, I would like to start testing it on my rom collection.


wally*won_kenobie said...

Wonder how we go about compiling this.

im getting u32 errors.

_Psycho said...

Just curious, I was compiling with the pspdevkit your source and it crash at the .S (asm) file (everything else was fine). Im not sure why yet, I didn't had a look, but just curious. Are you using the pspsdk toolchain from ps2dev in cygwin or something? I might go ahead and install everything but I was wondering first.


_Psycho said...
This comment has been removed by a blog administrator.
_Psycho said...
This comment has been removed by a blog administrator.
kersplatty said...

when i tried compiling it it says i need the 'build_locale.mak' lib file in the sdk, where can i get this

Sadranyc said...

Excellent! Keep up the good work! Can't wait to try out the updated version

wally*won_kenobie said...

I just found out daedalus doesnt compile with GCC. IF its not too much hassle, could you include such method in the future?

I wish to do what i have done with PSmonkeys emu, compatibility thingy but first i need to know what microcodes are implemented

PSdonkey said...

Everyone has been asking me that they cannot compile the new source and that they have been getting errors. I went ahead and compiled the new source for everyone and also added a couple of minor changes to the source for speed improvements. I also added an eboot icon and background to go with them. Here are the new compiled eboots for Daedalus Pre R5

Daedalus Pre R5 for version 1.00

Daedalus Pre R5 for version 1.50

Kramer said...

wow psdonkey actually helped people out for a change instead of being a complete retard

StrmnNrmn said...

insert display name here: I'll add an option to support the expansion pack. Theoretically it is just as easy as allocating an extra 4MB for the emulator, but obviously that's only possible if there is enough available memory. Currently memory is very tight, so I think it might take a fair bit of tweaking before this becomes possible.

wally: What errors are you getting? If you paste your error messages here I might be able to see what's going wrong.
There is limited (but out of date) support for compiling under GCC, so it probably wouldn't take too long to get things working (especially considering the codebase compiled under GCC for the PSP build.) I don't have time at the moment, but it's a possibility for the future. If you're looking to compile the PC version, you should be able to use the (free) Express Edition of VC++.

psycho: Yep - I'm using the pspdev toolchain (rebuilt about 2 months ago now).

For everyone who's having problems getting things compiling under the pspdev toolchain, this is a good guide to getting started. If you post your specific error messages etc I'll see what I can do to help you out.

Finally psdonkey: I'd appreciate it if you would post a link to your modified version of the source (as you're required to do as a condition of the license.) That way I can incorporate your speed improvements into the main build. Also, your links aren't working. I wonder why that is?

kersplatty said...

the rapidshare link for 1.5 is
all in one link blogger cant fit it in any ways can you bring back the framerate counter for next release its handy nice lil job tho
{ means the link is enclosed in the brackets

flyinghippo said...

Strmnnrmn, I believe the reason the links aren't working is because it doesn't fit in the comment window. Perhaps try selecting the entire thing and drag it all the way to the right. I will post them and see if they work.

1.0 Firmware Version of PSDonkey's Build

1.0 Firmware Version of PSDonkey's Build

Also, is there such a thing as a(n?) FPS counter in this build? I have run Zelda 64 and would like to report its speeds. Here is what happened;

The Legend of Zelda: Ocarina of Time 1.0 on a 1.50 PSP on PSDonkey's Build:

N64 Logo: Slow, no graphical anomalies.

Title Scene: A bit strange. Some ground disappearing on view of ground, and some small lines appear on the scene where Link and Epona appear.

Language Selection Scene(!?): Nothing but purple bars.

Naming Screen: A bit of black pixels randomly appearing from time to time. Hollow squares appear on the selected letters in the top row of letters, bottom row of letters, and second to bottom row of letters. Other lines also appear in other rows at times.

It then freezes and eventually blacks out when I select my name and the little board flips around.

I will try with some other games soon, such as Mario 64 and maybe Quest 64.

I am very pleased with this progress, Strmnnrmn, and PSDonkey.

Kramer said...

psdonkey did nothing

kersplatty said...

psdonkey compiled the new source for everyone, mario is a lot better and all textures seem ok, mario kart used to work but now it doesnt, cant start main game in starfox

Chewy said...

Both of PSDonkey's builds are on PSPUpdates now, and it works great.

I'd bet I'm getting around 15 fps right now.

Good job Stormin, and good job Donkey.

wally*won_kenobie said...

Some U32 variable stuff.

I think its because im using Msys.

Will try when i get my macbook :)

PSdonkey: Please dont claim credit for other peoples work. YOu are just turning into a next generation Yoshihiro.

But thanks for compiling it although nothing has been modified

kersplatty said...

hey chewy how do you know what framspeed your getting, r u jus guessing?

england 1 paragay 0! :D

Ogre said...

The fastest running games so far are AeroGauge (est 15-20fps), Mario (est 10fps) and StarFox (est 20fps)

wally*won_kenobie said...

I suggest you try
Bust a Move '99 (Runs at full speed but freezes after first shot with gun and gun is missing)

AtaruZ said...

kersplatty, you have to push "Select" to obtain the actual framerate!