Which is better: early PS1's with VRAM or later PS1's with SGRAM?

I was thinking about this topic for awhile but I never thought to a conclusion to this but let me explain the memory and how the PS1 utilized both. VRAM is a variation of DRAM but it is dual ported instead of single ported and is recommended with graphics cards of that time. However it was quite expensive to use. SGRAM, on the other hand, is yet another variation of DRAM but is single ported unlike VRAM. However, it can do 2 pages at once which sorta simulates VRAM (to an extent), can do bit masking and block write and was much cheaper to make than VRAM. So how were both utilized in the PS1? Well, early PS1 models (all SCPH-1000 and early SCPH-3000 and 1001's) used VRAM as the main video memory but SGRAM was used in later PS1's as the video memory (later 1001's, 5000's, 7000's, 9000's and 100's use SGRAM). So the question is this: why did Sony switch memory types? Were they faster? Was it because it was cheaper? Discuss!

 

Price and availability - VRAM never really took off, and a number of manufacturers dropped it from their line cards. This both puts the price up and makes it a risky choice as a key component of your system (especially since this was a point in time when there was a significant industry-wide RAM shortage). It was also obvious that SGRAM was going to be the mainstream technology going forward, so they went with that. The performance is generally comparable - alpha blending (and hence the PSX "semi-transparent" mode) is significantly faster with SGRAM, but blitting narrow (less than about 32 pixels wide) vertical strips of the display is slower.

There are also a few changes in the GPU that were not related to the different RAM - they basically addressed minor hardware bugs in the original silicon that had been previously handled using software workarounds in the library - the newer versions of the library looked at the GPU hardware version and patched out those patches if the console had the new GPU and didn't need them. This was another situation where the new machines could be faster - but in this case only if you had built the code using the new libraries.

Incidentally, this is the reason for the blue and green debug stations - the blue ones have the old GPU and VRAM and the green ones have the new GPU and SGRAM. Part of the publication requirements is that you had tested your title on both of them. The development boards all used the old (VRAM) based chipset, so the most important bit was that you did plenty of testing on the new spec machines.

 

Huh. Interesting. I wonder why in FF7, when the camera zooms in on the Mako power reactor in the first part of the game its slower than on my PS2 and PS3. And I knew that had to be the case. No wonder why they switched and redesigned the GPU to support it...

 

Was there any early games that didn't perform well on later SGRAM consoles?

 

Apparently there were a couple, although none of them were big sellers. I was told that the most common problem was that titles that used lots of transparency worked *too* well on the new hardware, and sometimes picked up a frame if they didn't explicitly specify the frame rate they were aiming for. An example (it's probably wrong, since this was a long time ago, but it should give you the general idea)

while (1) {
DrawSync(); // This normally (old silicon) takes > 1/60th of a second
VSync(0); // Wait for V Sync
DrawOT(); // Write out the ordering table
};

So, when you run this, it will normally give you 30Hz, since by the time you hit the VSync(0) call you have already gone past one sync pulse and have to wait for another. If you are using the newer silicon and it runs quicker then you hit the VSync(0) call before the first sync pulse, and you end up with one frame being emitted at 60Hz. The fix is really simple - just replace Vsync(0) with VSync(2), so you will never go faster than 30Hz.

 

Very odd. And it was obvious the lesser known games might have problems. Nobody really didn't care for them. Hope there aren't any more problems with some other games (Crash, Sotn, FF7, etc).

 

But what was SCE's stand on that? Was it documented that the refresh rate should be specified? If so, then the behaviour of such games were probably deemed as buggy.

@Sephirothkefka: the PlayStation games were in CD-ROMs, so nothing could have been done anyway. Not that they were ignored.

Wouldn't it be possible that the more obscure games might have less experienced developers working on them, which gave rise to poorer software designs that resulted in such glitches when the hardware was changed?

 

Unless if it got a Greatest Hits release or a silent disc re release. I know a Spyro game had that when some bad glitch happened.

Possibly depending on the experiences of the people developing the game.

 

There was a strong recommendation that you used either the root counters or the VSync callback for in-game event timing, and only used the actual display loop timing if you needed absolute minimum latency. In the latter case, you were also supposed to use VSync(n) to keep the timing consistent. So maybe not a bug, but still programming practices that went against the recommendations.

If you used the callback or root counters for timing, then it really wouldn't matter if you picked a frame - it might make the display look less smooth, but it wouldn't affect the actual gameplay. The other thing to remember is that this change was made early on in the PSX production cycle - so the Rev C. / SGRAM machines should really be considered the standard ones, since they represent about 95% of the PSX consoles ever made.