PlayStation Development Network

I've decided I'm going to base my work exclusively around interlaced mode. Obviously that means that I have only one video buffer. So as I understand it the normal arrangement is:

• use multiple ordering tables for buffering rather than multiple video buffers — you're buffering geometry you will draw, not pixels;
• install a VSyncCallback and within it (i) cancel any ongoing GPU activity; (ii) set the interlace flag appropriately; (iii) request a draw of the ordering table intended for the next frame;
• meanwhile the CPU and GTE tick over filling some other ordering table for a future frame.

So the question then: how do I ensure thread-safe communications between those two actors — the interrupt-driven callback and the main thread? Is the answer as simple as "MIPS is a load/store architecture, pointers are 32 bit, so if you're writing out a single pointer change then you can assume it's atomic, so just make sure the only thing you're pushing outward is the one latest ordering table address"?

I can't seem to find any mention of mutexs or condition locks or any of the other standard concurrency devices in the PlayStation documentation. It'd also be nice if there were some properly safe approach so that I could pass timing information back from the vsync callback and adjust my gameplay rate accordingly — i.e. I want to start doing more than just pushing one 32-bit value in one direction.

The 'Hello World' code I made has everything you need: http://www.psxdev.net/help/psyq_hello_world.html
It's based off of many great examples I have found

I guess the EnterCriticalSection() and friends can be used to protect critical data structures.

You can have two video buffers in interlace mode, by using one of the lower horizontal resolutions. If you can live with the limited number of textures you can fit in VRAM at once that is. I think Tekken 3 does 384x480 for example, which leaves room for clut tables below the buffers and textures to the right of them.

On the other hand, games like Internal Section manage to use maximum resolution, which makes it look really good.

It depends on the game. What I was really confused about was how there are two different layouts for the VRAM (SGRAM on models > than the SCPH-100x). The first is PAL, and the second being NTSC.

When in PAL mode, there is no room underneath the rendering area for the CLUT's and there is less room for textures since some room needs to be set aside for the CLUT's. However, a larger resolution can be achieved.

When in NTSC mode, there can be room for CLUT's under the rendering area since the resolution is smaller in height than the VRAM's total height (512px) and there is more room for textures. However, there is a decreased resolution.

What I was always confused about was can we use an NTSC layout in the VRAM on PAL games (and vice versa)? I believe Sony didn't want developers doing this, but I don't see why not. My Resident Evil 1 is PAL and they layout the VRAM in an NTSC fashion, so I assume it's perfectly fine to do. The only draw back would be the resolution being hindered whilst in NTSC mode.

Also, the rendering area can be used for storing textures should double buffering be disabled.

AmiDog wrote:I guess the EnterCriticalSection() and friends can be used to protect critical data structures.

That's almost exactly what I was looking for but hadn't yet found, thanks! So I guess to mark a new table as prepared I'd disable interrupts for the length of time it takes to store a pointer and grab a 'how many fields since I last did this?' count then turn them back on over on the main thread. Then the vsync callback, which executes as the result of an interrupt, can just assume it won't be interrupted by the main thread, so it can just increment the field count, figure out which ordering table to draw and draw it? And if the main thread discovers that all ordering tables are in use (e.g. if double buffering, just that it has prepared the next frame before the end of the current one) it can just block for vsync. Or a busy loop against a volatile flag, because power management isn't exactly a concern?

AmiDog wrote:You can have two video buffers in interlace mode, by using one of the lower horizontal resolutions. If you can live with the limited number of textures you can fit in VRAM at once that is. I think Tekken 3 does 384x480 for example, which leaves room for clut tables below the buffers and textures to the right of them.

I think I might as well just go for the largest resolution available. I'm a poor artist so textures aren't really a concern and, anyway, space looks ample. I've got space for around 200 64x64x4bits if I use a 640x480 video buffer, right? Also although I'm quite heavy on the modern OpenGL ES stuff day to day, my old-systems programming habit has so far focussed on 8-bit and assembly so even the constraints of high resolution interlaced mode are an incredible luxury.

AmiDog wrote:On the other hand, games like Internal Section manage to use maximum resolution, which makes it look really good.

What does the Ridge Racer High Spec Demo use? I remember that amazing me. Ditto Wip3out.

Shadow wrote:What I was always confused about was can we use an NTSC layout in the VRAM on PAL games (and vice versa)? I believe Sony didn't want developers doing this, but I don't see why not. My Resident Evil 1 is PAL and they layout the VRAM in an NTSC fashion, so I assume it's perfectly fine to do. The only draw back would be the resolution being hindered whilst in NTSC mode.

I would assume NTSC layouts all work in PAL mode based on the large number of extremely lazy ports we used to get back then — big black borders, 17% slower gameplay, the works. There were also a bunch of intermediate titles which were converted into PAL by fixing the speed and enlarging the game window quite a bit but not to the full screen.

Shadow wrote:Also, the rendering area can be used for storing textures should double buffering be disabled.

Which prompts the question: at what point do you become comfortable enough with your fast-enough-for-60Hz updates to switch to 320x480 single buffered from 320x240? I guess it was somewhere between Tekken 2 and Tekken 3 for Namco.

What does the Ridge Racer High Spec Demo use? I remember that amazing me. Ditto Wip3out.

Ridge Racer High Spec Demo is 320x512, not sure about Wip3out. I think the main reason the High Spec Demo looks so much better than the original is due to using gouraud shading a lot more.