PS1 Blue Debug PS1 slower frame rate than PsOne?

[Ichisuke]

I actually didn't know where to post this.... so... please move it elsewhere if needed, thanks.

So I was testing my blue debug PS1 and playing with FF8(never played the game on the console, just testing it).
I noticed some weird slow frame rate so I try the game on a PsOne and the frame rate on the One is smooth as it should be.
Both consoles are PAL (the PsOne is modded) and the game is the NTSC version.
The blue debug has the infamous color banding issue and cheaper GPU (or whatever they did with this version and some 100x units).
Could that be the reason? I've tried googling around but found nothing (only something about dithering quality over revisions).
The game slow down while in battle (using the summons) and the blue one is noticeably slower at some points.
Probably this is well known already and I've just missed it. I just wanted to know if it's normal and there's nothing to do or if the debug unit actually has some problems.

Thanks everyone.

 

[HI_RICKY]

pal and ntsc diffferent frame and scanline
different ver GPU different 3d mapping even is same game
you should use same video system PS test same system game

 

[Trimesh]

It shouldn't make any difference - there is a very slight frame rate error when running an NTSC game on a PAL console or vice versa, but it's < 1% and shouldn't even be noticeable. There is also no difference between the old and new GPU in this regard - they both use the same clocks.

 

[Ichisuke]

It shouldn't make any difference - there is a very slight frame rate error when running an NTSC game on a PAL console or vice versa, but it's < 1% and shouldn't even be noticeable. There is also no difference between the old and new GPU in this regard - they both use the same clocks.

Tried now with the same PAL game and the same thing happen. The Blue debug stays behind...

 

[rama]

I fully expected there to be a framerate difference.
The hardware is very different from another, using different memory technology and libraries that discern between "old" and "new" GPUs.
This is not well documented however, to the point where we can only speculate that the older hardware is slower in most games.

 

[Ichisuke]

I fully expected there to be a framerate difference.
The hardware is very different from another, using different memory technology and libraries that discern between "old" and "new" GPUs.
This is not well documented however, to the point where we can only speculate that the older hardware is slower in most games.

I think that's very bad... Back in those days a lot of people were playing with hardware that was not "finished"....

 

[Trimesh]

I fully expected there to be a framerate difference.
The hardware is very different from another, using different memory technology and libraries that discern between "old" and "new" GPUs.
This is not well documented however, to the point where we can only speculate that the older hardware is slower in most games.

Sony considered the old (VRAM based) GPU to be the reference and the newer SGRAM based one to be a special case, because the old GPU is the one that's used on the development boards. You could argue it's backwards because there are a lot more machines out there using the new GPU than the old one, but that was the position that Sony took.

Generally speaking, the new GPU is slightly faster than the old one - there are a couple of edge cases, one is alpha blending which is significantly faster on the new GPU and other is copying narrow strips of VRAM, which is about the only thing that's slower.

I can't honestly consider a difference in the speed at which primitives are rendered a defect - Sony always had the position that if you had anything where timing was critical then you should base it on the vertical retrace timing or the root counters.

You were, however, expected to check your code on the new GPU before shipping it - which is what the green debug consoles were for.

I guess it's also worth explaining the reason for the changes - when Sony originally designed the console they had to make some assumptions about which way the market would go - one of them was that EDO/Hyper Page memory would become mainstream (which was correct) and other was that dual-port VRAM would become the mainstream graphics memory (which turned out to be wrong).

This was significant because the cost of the RAM was a large part of the system cost and commodity parts tend to drop in price much more quickly - since dual port VRAM remained a niche technology and the PlayStation was selling very well it became obvious that they were likely to run into severe supply issues with it. During this same time period, SGRAM had become very popular in video cards, and hence they changed to using that.

This architectural change also greatly reduced the banding on the video output - in a VRAM system, the video DAC is wired directly to the read port on the RAM, and hence has to operate at the same bit depth as the framebuffer. Since the PlayStation 3D operations only work on 15 bit (5:5:5 RGB) video depths this means the DAC has to operate in 5:5:5 mode too - which only gives you 32 grey levels. When the design changed to SGRAM, the DAC went from being connected to the VRAM to being connected to the GPU and hence could always run in 8:8:8 RGB mode irrespective of the framebuffer depth. This allowed much smoother shading since the interpolated values sent to the DAC were no longer constrained by the framebuffer mode.

 

[HI_RICKY]

thank's Trimesh , it very clean and useful answer