|
|
|
|
|
|
| What is Play! ? |
| Play! is a PlayStation2 emulator for Windows, macOS, UNIX, Android, iOS & web browser platforms. For more information about this project please visit the "About" section of this site. |
| Compatibility Status |
|
Fetching compatibility status...
|
| Development Log |
|
Make "demo2d.elf" work.
Posted on 2005-09-02 00:00:00 |
|
Added the line strip primitive in the OpenGL GS renderer. The border around the blue boxes are displaying now.
Removed the old "Subject/Observer" stuff from the program and replaced it with an "Events/Delegates" system. This is used to inform the user interface that the PS2 virtual machine has been paused/resume or that the internal state of the machine has changed. Added a frame tick event to allow UI stuff to count frames for displaying a counter. Here's the result of today's work: 
Well, that's all for today. Happy birthday to me! |
|
Make "demo2d.elf" work.
Posted on 2005-09-01 00:00:00 |
|
First, I've added the LB instruction which fixed the problem where the demo goes into an infinite loop.
The rectangles where the text should be placed then started to appear, but the wrong texture coordinates were applied to those sprites because I wasn't using the coordinates provided by the UV register before. The coordinates were hardcoded as (0, 0) and (1, 1) so that we'd see all the font texture in one rectangle. I've changed the GS handler a bit to use the UV register values and the text shows right now. Then, I've tweaked a bit with the demo to remove the annoying delays so I could see what happens next:  
Those are screen shots taken from nSX2 that shows the next 2 screens. The blue rectangles were missing at first, because the case where we have a sprite primitive using ST/RGBAQ coordinates and no texturing wasn't implemented. I tweaked the GS handler again to save the RGBAQ register and added the case to render those coloured rectangles. Here's what I'm getting now:  
We can see that I'm still missing the nice yellow outlines. Those were made using coloured line strips and this kind of primitive isn't handled yet. We can also see that all the text is blended against the background for some reason in nSX2... I've checked the display lists and they are indeed being rendered with a previously set alpha blending formulae and with alpha blending enabled. But I'm not sure if that was the desired behavior or not. So, the next things to look forward to are the implementation of the line strip primitive and preliminary alpha blending support. |
|
Make "demo2d.elf" work.
Posted on 2005-08-31 00:00:00 |
|
This time I'll be working on making the next demo in this series work properly.
This one is based around adding font support to his framework. All characters in a font is stored in a texture and the coordinates of one character in this font are taken from a table stored in memory. It seems to use different fonts in the demo. It also seems to use some dirty trick with alpha blending to modify the overall color of the font. Right now, if I try running it, it gets stuck in the text printing function's loop forever because the LB instruction isn't implemented yet. That's what it gives: 
demo2d.elf running on Purei! In nSX2, it seems to be working, but the uber long dead loop the programmer used to introduce delays in the demo kicks in and it's hard to see more without changing the demo binary a bit... Something I've had to made to speed up things in the last demo too. 
demo2d.elf running on nSX2 By the way, all these demos are available on ps2dev. Sattelite tasks - Use a delegate/event system for FPS counting and already existing events. - Add the actual FPS counter. |
|
Make "demo2c.elf" work.
Posted on 2005-08-29 00:00:00 |
Added the alpha testing support today. It was really easy to implement since OpenGL supports the same functionality with GL_ALPHA_TEST and glAlphaFunc. It was just a matter of using the values from the TEST_x GS register and apply them to the OpenGL functions. Here's the result:
demo2c.elf 
demo2b.elf I've also fixed a crash that was occuring on my other computer when I was closing the emulator. This was simply caused by not cleaning up the OpenGL rendering context at the end of the program. I've also fixed a small issue with scrolling in the binary data views of the ELF file viewer. This development can be considered complete now. |
|
Make "demo2c.elf" work.
Posted on 2005-08-27 00:00:00 |
|
LIBC streams buffering is a bit wierd under MSVC++... In "Debug" mode it seems to have line buffering enabled, and in "Release" mode the buffering seems to be disabled. That's what was causing the log not to update in "Release" mode. Also, it seems that line buffering isn't supported in Win32, so I had to resort to make my homemade buffering and use the no-buffering mode on the stdout stream. It's working good now.
Another problem was that it was crashing when I was pausing the virtual machine. For optimization purposes, the address to the Sleep function was kept in ebx and this register wasn't properly saved by the recompiled code... So I simply added pushes and pops before calling the recompiled code and it fixed this problem. Made the v-blank bit reset when you write 0x08 in the CSR. This allows us to use bigger values for the count-down counters. Using bigger values makes the emulator spend more time executing the code rather than swapping the video buffers, but slows down the animation speed. Also added the SLTIU instruction. The demo can run completely now. Next and final step for this development is to make the alpha blending (or testing) work. |
|
Make "demo2c.elf" work.
Posted on 2005-08-26 00:00:00 |
|
I decided to add a parameter to the tick function (which is the number of cycles executed) to be able to support the case of skipping a whole execution quota to abort a dead loop. I haven't seen much of this stuff yet, mainly because I haven't played with any demos that use interrupts. This ticking function setup shouldn't have any trouble handling these cases, if there's any.
Now, a counter is decremented by the number of ticks when the tick function is executed, and when this counter underflows, it will set the v-blank bit in the CSR and set the counter to another value. Once the counter underflows again, the v-blank bit is reset and another value will be loaded in the counter, etc. The display buffer is also swapped when the system enters the v-blank state. I don't have the real values for these counters right now though. The cycle number needed for rendering a line would be something along the lines of the CPU frequency of the EmotionEngine divided by the number of frames by second, divided by the number of lines in the current display mode. Then we'd need to know the number of active scanlines the system renders and the number of scanlines the system blanks. Anyways, I just used fake values for these now and the result is what we would expect: we can see each frame of the scroll down animation. The counters just affect the speed of this animation. The required v-blank stuff is mostly complete for now. I'm just wondering what's the effect of writing 0x8 into the CSR, because the program writes this value into this register before the loop that waits for the end of the v-blank. Maybe it resets a possibly active v-blank flag? I'll have to check that later. I've also moved some of the stuff from the OpenGL GS handler to the base GS handler (like writing and reading to the private GS registers). That's just to make the stuff cleaner in the source code. The emulator has a lot of trouble running in "release" mode right now... And the screen updating is still screwed up for the previous demo. I'll have to investigate these next. |
|
Make "demo2c.elf" work.
Posted on 2005-08-25 00:00:00 |
|
Sorted a bit the placement of the "ticking" function today. This function is called after each instruction is executed to increment counters, check interrupts based on these counters, check breakpoints, invalid instructions, etc. It was in the recompiler class for some reason before and I moved it into the main virtual machine singleton class.
This way, I can increment a cycle counter to eventually make some check to set or reset the v-sync and h-sync bits in the CSR. Just wondering what would be the best way to maintain this counter right now... Incremeting it by one each time the tick function is called and checking the value to set the bits would work for now. But it'd surely screw up if we'd wanted to implement some dead loop skipping mechanism later on. And I musn't forget about the COP0 Count register too... Guess I'll ponder a little bit more. |
|
Make "demo2c.elf" work.
Posted on 2005-08-24 00:00:00 |
|
The logging class is suiting my needs right now. Isn't as bad as it was before. All the internal buffering was removed and it lets the Win32 edit box take care of the memory.
Some ideas I had for improving the logging stuff in Purei: - Add a menu to enable or disable logging in the different parts of the virtual machine (CPU, GS, DMAC, OS, etc.) - Add an option to dump the log into a file by right clicking on the log window. |
|
Make "demo2c.elf" work.
Posted on 2005-08-23 00:00:00 |
|
Nothing really interesting today. Just investigated a better way to implement the log since it was really crappy the way it was before. I've made it so it uses a fixed size buffer now, which will make it a bit less of a memory hog and a bit faster when a lot of output is generated.
The way it's scrolling is still bugging me though... I'll probably look into fixing that tomorrow... And saving all the log output to a file would be something nice to do to... Maybe in a later version. |
|
Make "demo2c.elf" work.
Posted on 2005-08-20 00:00:00 |
|
Time for working on other demo! This is the state where I was currently at when I stopped working on the emulator last time.
This demo specifically relies on v-sync for swapping the buffer at the right time for reduced tearing. Looking at the source code and documentation that came with the demo, it seems that this program first scrolls down the tank picture down, increasing its visibility by 2 pixels after each v-blank. It then waits a bit, then scroll a text around the screen, waiting for v-blank after each movement. And it finally goes back to the background scrolling part. nSX2 seems to play this demo fine, but it skips a lot of frames for some reason (might be related to the GS renderer). 
(demo2c.elf running on nSX2 v0.08) It works a bit in Purei too, but the v-sync bit in the CSR (0x12001000) is not set or reset correctly when the virtual machine should be in a v-blank state. So we see the background scrolling very fast towards the bottom when it should only go down at each 1/60th (for NTSC peeps) of a second. 
(demo2c.elf running on Purei!) We can also see that the alpha blending is not handled at all. I'll have to fix that after fixing the v-blank periods. Tasks: - Add a v-blank period notion. - Add alpha blending to the GS-renderer. - The new way of handling flips breaks the optimized binaries. - Improve the log. |
| << Older Log Entries | Newer Log Entries >> |