- Created on 02 February 2015
- Written by Gregory
Hello PCSX2 followers,
After a long delay, this is the second part of the MMU mini-presentation. In the previous chapter we saw that MMU allows giving a virtual address space to a process. Besides, I told you MMU controls the cache behavior (cacheable/uncached accelerated/uncached). First, let me quickly explain the different cache accesses. Then I will introduce the default memory mapping of the PS2.
- Created on 23 November 2014
- Written by Gregory
Hello PCSX2 followers,
It's been a while since the last developer blog entry. I would like to resume this old tradition.
I will present you a mini series on the MMU (memory management unit) and virtual memory. Jake and ZeroFrog already wrote some posts relating to this topic:
This time, I will explain the goal of MMU and why it is mandatory for modern systems. The MMU is a cornerstone for stability and security. I will also explain why it could be costly for the performance on the native system.
On the next article, I will present you the PS2 address space and how the MMU is really used.
- Created on 16 November 2014
- Written by bositman
After quite some time, I take the chance to write up this blog post about our wiki, in place of our wiki overlord and forum member ng!
Here it is:
Salutations the fair people of PCSX2 land! Did you know we have a wiki in our borders? Well, apparently we do! And for more than 5 years now this wiki is waiting for someone like y'all PCSX2 geeks to help it thrive and to be the beacon of hope for those new users who desperately seek help in the ocean of boundless Internet. But some of you didn't even suspect of its existence!
In all seriousness, 5 long years have passed for PCSX2 wiki and we could say they were mostly quiet years. We had our share of fun though, and went through many changes. For example just recently we've adopted test tables and any of you can add your own test case or in-game issue so that new users can solve their game related problems quickly and comfortably. The wiki enjoyed many good contributors during its years. These people are the ones who really built it, filled it with information and helped it to become what it is now. It's difficult to mention all of these people in this small article but to those who have contributed to the wiki over the years we have an enormous gratitude! The wiki is in your perpetual debt!
Although we have many informative game cards a huge number of lesser known games are left without any test cases, issues, images or additional info. So we appeal to all of you who has a small amount of free time and a tested (or completed) game on your hands (whether it already has some test cases or not), -- you're more than welcome to register at http://wiki.pcsx2.net/index.php?title=Special:UserLogin&returnto=PCSX2+Wiki&type=signup and add your contribution to the wiki. Besides test cases the wiki could use some updates in general articles and guides (they are quite outdated).
Last but not least, anyone with designer skills can try his hand in re-designing the main page which is pretty old and honestly was never a real looker. And generally to those who want to fill any info, complete pages, fix errors, re-phrase sentences and do stuff, your help is sincerely appreciated!
- Created on 04 September 2012
- Written by General Plot
I know this has nothing to do directly with PCSX2, but I thought this occasion deserved an announcement here, as without PCSX2, this never could have been possible. I met refraction's sister nearly five years ago after knowing him for a few years. And as everyone knows, I'm married to his sister. Today his sister and I celebrated the birth of our son. A child made possible (as odd as it may seem) only by this project.
Many people look at the emulator as strictly software, and the human side of it tends to be forgotten, but this is one of those cases where it's all about the human side of it. An epic emulator that brings about the possibility of an epic life event. It's not big, but this project has rewritten the history of our lives and bring a new life into it.
As much as I love this project (always have), no amount of speed increases or bug fixes can compare to the excitement that comes with seeing my son born today. I'm sure to most people, this isn't important to them, but I wanted to share it with anyone who might be interested. Just consider this as a reminder of the human side of it.
- Created on 02 September 2011
- Written by refraction
I promised myself ages ago I would write a blog about this, more for the PS2 community than anything else as this seems to be almost a dark art in terms of understanding how it works.
Some of you may be familiar with Path 3 masking, some of you may not. In any versions around 0.9.4 or older, have you ever played a game where say some of the floor textures have had writing on them or just looked like absolute crap? Well the likelihood is that was due to Path 3 Masking problems. For those not familiar, here is a picture example of Persona 4 displaying Path 3 masking issues.
So, what is it exactly?
Path 3 masking is a method of synchronizing the order in which geometry data (polygons etc) and the textures that go on them are sent to the GS (Graphical Synthesizer). It was a pretty efficient method of transferring information, which took completely different path routes to make optimal use of the PS2 Memory BUS and used a stalling method to keep the texture and geometry lists in order instead of interrupts which took extra cpu time. This way, developers could queue up massive amounts of textures and stream them to the GS in time with the geometry data efficiently.
Here is a badly drawn diagram showing what the Mask does:
As you can see, the mask stops PATH3 from transferring while the VU is busy, then lets it go and almost immediately puts the mask back on, this ensures that at the end of the texture transfer, PATH3 stops again!
So what was the problem? Why did everything look like crap?
Truthfully? we never had proper control over these packets. The GIF packets can come through the PATH3 DMA channel lumped together, where in actual fact, we should have been stalling half way through it, but in the emulator, we didn't really care what these packets were, so we just threw it all at the GS and ignored any packet ends and this is what caused the Texture/Geometry lists to go out of sync, this is where the crap on the screen came from. As the emulator evolved it became progressively easier to fix this issue, although we had the theory down, developers would handle it in different ways with different timings for the masks, so it took a fair amount of testing and tweaking to get right.
Fortunately these days we have got this pretty much solved and we completely analyze the GIF Packets before sending them on their way, so we know where we can stop the transfers, however we do still get the odd time where this rears its ugly head, due to how we have to time everything perfectly, but due to the nature of emulators, timing is painful to get correct and will probably never be so. Generally however, using gamefixes such as "EE Timing Fix" can get around these issues, without compromising too much on stability.