All right, so yeah, we have Daniel, how did I pronounce your last name?
Daniel Welcher.
Okay.
So Daniel Welcher, he did some very interesting work that is, I guess, unusual, because most
of the emulation we see is on PC, so this is different, and me personally, I'm very
excited to see this start, which is starting 10 minutes late, but we're going to figure
it out, so right now, I'm going to go there, take it away.
Okay, so my talk today is called Pushing the PSP, and it's about writing two emulators
for the PSP.
So I wrote this with the help of one of the other main developers on this project, Zero,
or Lorenzo, but he can't be with us here today, so I'm presenting on his behalf.
So a bit of background on this talk.
It is mainly about Dreamcast and DS emulation on the PSP, like I said, and this was first
attempted about a decade ago, around 2009.
There were proof of concepts made for both consoles on the PSP, but due to the small
power gap, it was quite difficult to emulate them at any good speed, and they remained
proof of concepts.
But today, much better tools are available, and much better understandings of all platforms
involved are available as well, so we'll see how a newer team gets on.
So a quick primer on what the PSP has to work with.
The main CPU is called Allegrex, and it's a MIPS CPU at 333 MHz.
The GPU is a custom Sony graphics card at 166 MHz.
The resolution is about a little less than 480p, and we have 32 MB of RAM as our baseline,
although most models are 64.
We have another chip of interest called the MediaEngine, which is exactly the same as
the main CPU, but lacking a vector unit.
That chip will become a big talking point later, because developers officially couldn't
write arbitrary codes to this chip, but we can.
So we'll start with the DS, because this one is the lighter, easier machine, hopefully.
So the DS is, as I said, a much lighter machine than the PSP.
We're looking at an ARM chip at around 66 MHz, and a secondary ARM chip at 33 MHz.
There's no modern-looking GPU in it, so we just have about 656 kilobytes of VRAM and
4 MB of RAM, so in theory this looks quite doable.
The first efforts trying to emulate the DS on PSP were by a developer called Yoshihiro
back in 2009, who ported an old build of Desmume, which many of you may know as a popular
Nintendo DS emulator to the PSP.
It booted a lot of games, but as you can see from the frames per second counter in the
top, it did not run very well.
For those who can't see at home, that says about four, okay, out of 60.
So we've a bit of work to do.
It's a very basic proof of concept, but it's an exciting effort, because as you might
realize, both of these systems released in 2004, they were still receiving games at this
time, so we were effectively playing games on the rival platform.
But today the code is quite outdated, Desmume has come quite far along, and it was never
very well optimized in the first place.
So the challenge is with emulating the DS on the PSP specifically.
First of all, we're probably going to rely on an interpreter, at least for the beginning,
which is quite slow, more on that later.
The touchscreen, of course, the PSP does not have a touchscreen, so we'll have to find
a way to work around this.
The unique graphics architecture, we have a 2D and 3D engine as opposed to a more modern
graphic solution, and of course we have the two-screen problem, of course.
How do we present two screens on one is one thing, but the resolution doesn't quite seem
to fit either, so we'll need a unique solution to try and scale things as well as we can.
And then the last question is, what DS emulator can we use as a base?
Because while Desmume was the obvious choice back in 2009, many other options have popped
up since.
So these were the three emulators we mainly considered.
On the left we had Desmume, we just use a newer build of Desmume.
It's the most complete, it has high compatibility overall, it is a bit slow, it has a lot of
old code and it's missing some extra features, and the developers won't give us much support.
MelonDS is a newer emulator released many years after the original proof of concept.
It's mostly complete and it's faster, but it's a work in progress.
NewDS is exactly the same situation.
The developer is quite helpful and we did actually get in contact with him to help us
building it, and it is underactive development, but it is the least complete.
Though it is portable, so all of these three emulators are worth a look.
So we started with a more modern build of Desmume, around 2020.
Zero led the charge on this one, and he began porting the most recent stable build of Desmume
to PSP, and there's some success.
Many games boot and 3D does work, but because we're only using an interpreter as opposed
to a more efficient means of translating the code, we're still not seeing great speeds.
For those of you who can't see, we're looking at about 5 frames a second on Super Mario
and about 17 on Yoshi's Island, so about a quarter of the speed maximum right now.
So we'll see how we can improve.
So what can we do?
Well, first of all, we can use the PSP's GPU.
We can accelerate drawing with the inbuilt graphics hardware, at least 3D drawing.
We can use the PSP's VFPU to optimise maths and similar functions.
We can underclock the emulated system, hoping that we can skip some cycles and games and
performance, and like I mentioned earlier, we can use the media engine.
So just to explain a little bit about this chip, this originally could only be accessed
through a Sony API by official developers.
That meant it was pretty much limited to tasks such as audio and media decoding.
But for us, we can take advantage of this to do whatever we really want.
And so now the question pops up, could we even emulate the second DS CPU on our second
CPU?
Could we offload some functions to it?
We have a lot of options here, but we'll have to do a little bit of thinking to figure
out how to use it.
So the first steps are hardware rendering, moving our 3D rendering to the PSP's GPU.
And in fact, this demo runs at 71 frames a second from 20, using software or CPU-driven
rendering.
Of course, there are newer issues introduced.
You can see the dice is now missing its face texture, a little issue, but we fix it eventually.
And it also saves some CPU resources, so it will hopefully have even more knock-on benefits
for the emulator.
So the big step is a dynamic REC compiler or a Dynarec, and just-in-time emulation.
So I'm sure many people here know about what a Dynarec is, but just to recap, it is compared
to an interpreter.
An interpreter fetches and executes instructions one by one, and it would never be fast enough
to emulate the DS on PSP.
But a dynamic REC compiler translates to native code and caches it, so we can run much more
of the code as if it was natively for the PSP.
So far, so good.
So the Dynarec at this point was less than half finished, but we are getting some big
speed gains.
Basic 2D scenes reach or even exceed full speed.
That Zookeeper demo earlier is now running at over 50 frames per second.
In fact, just for comparison, the PS Vita build, which was not optimized, runs this same scene
at 22 on much newer hardware.
So we were off to a great start, doubling the performance on a newer console.
But 3D is still very slow because that's quite a complicated thing, so very little gain.
It's difficult to see here.
Professor Layton at the top is actually reaching an exceeding full speed, but the 3D drawing
is still at about 13 frames a second in a real game situation.
So the question is, does Moomi is too slow?
Does Moomi's convolutional RK code is a big factor in the performance here?
Because the emulator is about 20 years old now.
It was one of the first efforts to ever emulate the DS on PC, let alone on PSP.
So we ran a little test.
Zero compiled Moomi on his computer without any optimizations, turning off everything
from the compiler and seeing how the emulator ran with pretty much no optimization.
And even on a modern computer, Pokémon was barely reaching full speed.
So resolving some of these speed issues would require a major refactoring of already a large
old emulator.
So time to explore our other options.
Does Moomi would require a lot of reworking to get optimal speeds?
So what about the other emulators?
Well, new DS shows the most promise.
It's clean, simple and portable, even if it's early in development.
So can we use new DS to better utilize the PSP?
Well, at first there were signs of promise.
It has a very good start.
And initial results seemed quite promising.
Even in the very early build where we hadn't even fixed RGB color issues, we were seeing
over 50% speed on Yoshi's Island, that same game that was running at 17 earlier.
It's neater.
So each loop calls function distinctly.
So drawing, rendering, DMA, all these things are called as individual parts of the function,
meaning it is easier for us to split it up between both chips.
And it means we might be able to parallelize the code a bit better as well.
So we can use that media engine for a bit of extra performance.
But it's harder than it looks in the end.
So some cash problems emerge here.
As some of you may know, having developed for dual core systems, it's a bit different
when you move to dual CPU.
See, when you try to access the same code on both CPUs, you need to flush the cash.
And this wastes a lot of time.
This on top of things like scheduling issues and trying to balance between both CPUs led
this to be a bit more difficult than we'd initially imagined.
On top of that, NUDES was a very different code base, and we would need to re-implement
our work on hardware acceleration and our dynamic recompiler.
So that itself is a lot of additional work.
And like I said, it's still a work in progress as well.
So this emulator would still need more time, even if we finished porting it ourselves.
So back to the drawing board.
Despite its flaws, this movement still seems like the best option.
NUDES would need a lot of work, both from ourselves and from the developer before we
was in a complete state.
And optimization is also not there either.
So the other alternatives also turned out lacking.
Any of you with an Android phone trying to play Nintendo DS games may know of Drastic.
This is a very popular, very fast emulator, but it's closed source, and that kind of rules
that one out pretty quickly.
Meland DS is also an option, but it's very threaded, and that doesn't really work well
on our single CPU machines, or in our case, dual CPU, for the reasons I mentioned earlier.
So where are we now?
Well, we've stuck with it as the main DS emulator for PSP, and it's at a pretty good state.
Many games do boot.
Some 2D games are indeed playable with Frameskip, and of course sound disabled on that note
as well, because that is a whole different beast to emulate right now.
The JIT or the Dynarec is implemented, but it's very inefficient, and it could be much
faster.
And I'll return to this later, but we can use knowledge learned from our Dreamcast
JIT to improve our DS1.
In other words, we learn a bit more about the PSP through various different emulation
projects, and we can use it to improve all of them.
So what's next?
Well, first of all, complete the JIT.
It could be hard as the PSP is short on RAM, and we can't cache that much code, but work
can still be done.
We can optimize the emulator for new compilers, so we don't actually use the latest toolchain.
That introduces new issues, new bugs, new crashes, but that could in theory get us some
extra performance.
We could try to use HLE or higher level emulation for the ARM7, which is the second CPU on the
DS, which as opposed to lower level emulation, which would be emulating the chip more directly,
this would only emulate the necessary commands and functions that the DS would have used.
This would save us some performance, but again, a whole different beast right now.
And the final thing is PSP1000 support, which is support for the 32 megabyte RAM models.
As I mentioned, we're already short on RAM, but we might get there one day.
So the second half of this presentation is about the Dreamcast.
And this is a much bigger challenge, Germany, than the DS.
Let's have a little comparison here.
So the Dreamcast is a few years older than both of these systems, but its CPU is a Hitachi
SH4 at 200 megahertz.
Moreover, the GPU is actually a bit slower, but has more memory than we actually have.
We're looking at 16 megabytes of RAM and 2 megabytes of sound memory as well compared
to the DS's 4.
As you can see, we're kind of up against it here.
If we go by the rule of thumb, the emulation requires several times more power than the
original system.
This could get difficult, but we'll see where this goes, at least as a proof of concept.
So the first four port for a bit of backstory.
In 2008, Dirk Rasil, who's now known as Skimp, ported his emulator, NullDLC, to the PSP as
a little proof of concept, basically for a bit of fun, and it booted commercial games.
This here is the Dreamcast BIOS running on the PSP, and it's pretty much feature complete.
It's slow, but it works, and that is a big start.
But there are some glitches and issues.
So I have here some footage from the original emulator.
Now bear in mind, this build, the binary and the code, was lost for a long time, so this
is drawn from YouTube from the time, so I apologize in advance for the quality.
This is footage of Shenmue from the Dreamcast running on the PSP in 2008.
It's a little problematic, shall we say.
But the fact that this is booting at all is a big step.
And we're looking maybe at about 20% speed here.
This was a big budget title perhaps around the year 1999, so the fact that we are emulating
this at all is quite a big achievement.
I think we peak at around 25% speed here, but there are clearly issues with hardware
culling, transform, texturing, pretty much the whole boat of graphical issues is on display
here.
Crazy Taxi, we thought would fare better being an arcade game, but this is more interesting.
It is so slow that it practically doesn't appear as a video here, right?
We're looking at literally about three frames a second.
But this is interesting because we thought Shenmue being one of the most expensive games
of the time would be more difficult.
Is the footage still running?
Yes, it is.
It's that slow.
So we thought Crazy Taxi would be easier to emulate, but as it turns out, it looks like
this has some unique quirks for our emulator.
So a few years later, the source code actually returns.
Our friend Skimp finds the source code again somewhere, and he puts it on GitHub around
2017, almost 10 years later.
So it was added to the PSP archive, which is a GitHub repository in 2021 after it's
cleaned up and confirmed to compile.
This is where we come in.
So we began to compile the emulator again and make some adjustments.
Games do boot, albeit with some issues, but there is some promise.
For example, the game here, I believe it's Powerstone or one of these fighting games,
is actually hitting up to 38 frames a second, despite some obvious graphical issues.
So it's a pretty good start, I'm sure you'll agree.
Turn of the King, original developer Skimp actually returns to help us out on this project
and helps us to plan out how we should use the PSP hardware.
Obviously, he has been developing a Dreamcast emulator for many years, so his expertise
has been invaluable.
He helps us with parallelization, hardware expertise, and he actually believes that full
speed emulation for the Dreamcast is possible on the PSP, which is definitely not what people
would have thought 10 years ago.
To work on the jit begins, it's early, but it's a work in progress.
The first full speed milestone.
Big titles are getting better too.
Here the game Mr. Driller becomes the first Dreamcast game to run at full speed on the
PSP, something we never even thought possible.
Though there are of course a few caveats, there seem to be some texture corruptions going
on and the performance does not stay above 60, but this is a big milestone for the emulator.
Like Adventure on the other hand is a much more complicated game, it's running at about
25% speed for comparison, but it's a good start.
Audio is still too big a performance here right now to reliably implement, but we might
get there.
So this brings us to another new chip.
I mentioned the media engine earlier, but it actually has a chip related to it called
the VME or the Virtual Mobile Engine.
This is a reconfigurable chip that was designed for media decoding, but we still don't understand
much about it to this very day, almost 20 years after the PSP released.
It's a bit like an FPGA in the sense that we can reconfigure it in software and it's
capable of 5 giga operations a second, so if we figure out how to use this chip we could
see big emulation gains, but at the moment we are still a little short on knowledge,
so this is more of an area for the future.
In terms of optimization and what can still be done, first of all audio, like I mentioned,
in theory we could offload this to the VME once we figure it out, but if not the media
engine might still do the job.
Texture optimizations, textures are currently stored in RAM, meaning that there is a speed
penalty in transferring them to video memory and then rendering them.
Once we find out how to move things around more efficiently we'll find some performance
there.
Rendering bugs, as you saw earlier, are still there due to some problematic implementations.
So here's some footage from 2023 of the latest build, same scenes recorded more recently.
As you can see Shenmue is still struggling for performance and there are actually new
issues altogether.
The main character is now running in a completely different direction, but we are seeing much
better performance.
In fact this hits up to 70% speed and sure there are still hardware culling issues on
display here, but the fact of the matter is we're looking at nearly full speed already.
And finally we have crazy taxi here.
It's finally looking like a motion video, which is fantastic.
It still requires a lot of work, but you know what, considering what you saw earlier I think
we will take it.
So the state of play, just to recap, there's a long way to go, but there is a lot of progress.
The early jitter implementation gets us some speed at the cost of some instability right
now.
It's already up to three times as fast as the original build, perhaps more, and we're
seeing full speed in some games.
3D graphics are completely hardware accelerated right now, but the implementation is not yet
finished.
So the future is bright.
This is the note I will end on.
Despite key areas of the emulator in early stages, progress is very good.
We're seeing full speed in some cases, which is more than anyone may ever have expected.
Big budget games like Shenmue are heading up to 75, and once stability improves and
our JIT comes along a bit further, who knows where the future could take us.
That's the end of the presentation, but before I go to question, I'd just like to thank
Zero, as he was the main developer on both of these projects, unfortunately he cannot
be here today.
And additional thanks here to Skimp and HLiD, who provided us help with our implementations
of the JITs on both machines.
So that's the end of that presentation.
Do we have any questions?
Thank you.
So do we have any questions?
Yes?
Is the dolphin in the next project?
Is the dolphin emulator our next project?
Yeah, in the next project.
One more time?
The dolphin in your slide.
Oh.
We will see, that was actually from a Dreamcast game called Echo the Dolphin, which is why
I used it as an image there, but we'll see, maybe I'll use the dolphin next time.
Any other questions?
Yes?
In this new version of this movie, what is the impact on the battery of the PSP?
This is a good question.
Okay, so originally the PSP, oh sorry, so in the modern version of this movie, what is
the battery impact, is the question.
So this is a very good question because battery was always a concern for the PSP, especially
at launch.
In fact, Sony limited the PSP to 222 megahertz at launch to prevent battery loss.
The battery is actually the same in terms of battery usage compared to the original
build because we've been running at 333 megahertz the entire time.
So in the end, there is little to no change in battery consumption.
Anything else?
Yes?
Okay, good question.
So this is about underclocking the emulated CPU.
So if we say here that the DSH CPU is running at 66 megahertz, I think that is what I said
earlier anyway, and then we could potentially save some performance by emulating the CPU
at a lower clock speed.
So we could emulate, say, a 50 megahertz DS.
This might come at the cost of some in-game performance but would lead to some more stability
and some more performance consistency, if that makes sense.
Or some games that do not fully utilize the DS might actually just see some free performance
altogether.
Does that answer your question?
Thank you very much.
Yes?
You mentioned one possible optimization to skip code that's basically not, you know, only
when the, only emulate the essential parts.
Yes, do you mean higher level emulation?
Yes.
So being a little bit like, first of all, is that static, like you just know beforehand
which command or which code you can skip?
Exactly, like how much improvement can you get from that?
Okay, so the question is about HLE, so emulating some, only the necessary functions on the
DS's second CPU.
To be honest, I'm still a little bit in the dark on the specifics of HLE, but I will
say this.
The idea is instead of emulating the chip in a traditional low level sense, we know
that this chip can only use a handful of functions, right?
So this chip was dedicated just to a few sound or auxiliary functions.
So we try to emulate these, how do I put this?
We try to, we know that there are only a few functions to emulate, so we focus on those
if that makes sense.
That is the concept of higher level emulation, although I can't unfortunately answer all
the details about it right now.
Thanks for the question.
Yes?
I'm just wondering if you can say a little bit more about the JIT, like, is it very naive?
Is it just getting rid of the overhead interpreter, or does it actually do some sort of a registration
or local optimizations that translate?
So is your question about the JIT for the DS or the Dreamcast, or both?
Both, okay.
So like I said, Xero was the main driving force on both JITs, and he had some help from
outside, so I'm not fully aware of the current state, but I can say that from what he's told
me, the DS JIT right now is complete, as in all the op codes are implemented.
But the implementation is naive, so it's quite inefficient right now.
He didn't quite elaborate on what parts were inefficient, but that was the gist.
As for Dreamcast, it's actually not fully implemented yet, but he says it's a more efficient
implementation as per the PSP's hardware.
Is that answer your question?
Thank you very much.
Yes?
What's the compiler tool transport for PSP?
Can you just use upstream GCC or back?
Yes.
So, sorry, the question is about GCC and modern compiler tools.
Yes, we actually do keep the PSP quite up-to-date in terms of the tool chain.
We tend to use GCC 11, if I recall, or quite a modern version of these upstream compilers,
but this one is actually built on a tool chain that's a few years old because the newer ones
introduced some instability.
But to answer your question, yes, it's mostly upstream compilers.
Anything else?
No?
I think that's good.
Oh.
What's the question?
So, you showed some triple A games and some smaller games, had you tried homebrew or custom
built stuff just to maybe even unit tests, so unit tests, you were having a lot of sound
issues just to narrow that part of the emulation down in a custom built software, had you thought
of that, or is it all just kind of pre-built, whatever you get?
Okay, so your question is have we tried homebrew programs on either of these emulators?
Well, actually, there was one or two homebrew pieces featured here.
You might remember there was a dice demo displayed for the hardware acceleration.
We used that as a simple way to test whether the 3D rendering worked, but the problem with
homebrew is that often this uses code that's, shall we say, a little bit unofficial, and
this can cause whole new issues that wouldn't really apply to commercial games.
So we tried to avoid it, but we do use it sometimes to test particular things.
Does that answer your question?
Thank you very much.
I do ask a question.
Yes, go on.
What do you ask a question?
How do we debug this?
On the PSP?
Yeah.
Okay, so how do we debug?
This is a pretty good question.
So with the PSP, we can plug it straight into the computer, obviously, using a USB connection.
There is a tool, what is it called?
I forget the actual name of the tool now, that's how long it's been, but basically there
is a way of, you can send the PRX, which is the binary, to the PSP, and it is connected
to the computer still, so you can log what's going on in the memory, on the computer side.
Okay, but no breakpoints.
No, no, no, nothing too fancy that I know of, anyway.
If someone does know more about that, and I'm not using it, then that's great.
Last one?
Yep.
All right.
Thank you very much.
Okay.
Thank you very much.
Thank you.
Thank you very much.