The classification on Wikipedia (https://en.wikipedia.org/wiki/PlayStation_models) doesn't make a lot of sense to me, as for instance the older PU-8 boards with 160-pin GPU+ VRAM and newer PU-8 with 208-pin GPU+SGRAM are both lumped together as Rev. B hardware. Is there any unique aspect about the PU-7s which explains the Rev. A listing?
They have had some weird boards mixed and matched together @TriMesh can give an easy explanation as to why this happened
Yeah, the reality is a bit messier and doesn't fit into that table format well. That A/B/C really refers to the GPU revision. Revision A was in early Japanese units and had a few minor bugs that were worked around in the libraries. When Sony started planning for release outside Japan, they did a respin of the GPU that fixed the bugs - this was Rev B. From a developer point of view it didn't matter, since the minor differences were hidden by the run-time library. Some time later, VRAM started getting expensive and in short supply and the GPU was re-engineered to use SGRAM instead - this was Rev. C. That one did have some programmer-visible differences - everything still worked the same way, but the timing was changed. Mostly it was faster, but there were some special cases (notably block moves on narrow vertical strips of the video memory) that were significantly slower. That was why they made the green debug stations - the DTL-H2000 uses the old GPU and there needed to be at least some testing on the new one before release. It's not clear why the board number stayed at "PU-8" - the early engineering models used "PU-9" as the board reference, which would seem to make a lot more sense, but in the end they kept the same board reference despite the substantial redesign. Rev. A: Most (possibly all) SCPH-1000 Rev. B: SCPH-1001 and SCPH-1002 up until the change to the new GPU and SGRAM*, SCPH-3000/3500 Rev C: SCPH-1001 and SCPH-1002 after the GPU change, SCPH-5000 * = Allegedly there are some SCPH-1001 with the Rev. A GPU.
Ok, would this mean that the changes on the GPU from Rev. A to B were unmarked though? All VRAM boards I've seen use the same CXD8514Q+CXD2923AR combo, even this PU-7 with 9446 date code on the CPU: https://i.imgur.com/MZaBye7.jpg As per this thread (http://www.psxdev.net/forum/viewtopic.php?f=47&t=1035), the dithering on gouraud shaded polygons was improved with the CXD8561Q GPU on late PU-8s, a change quite visible even to the user. That PU-8-21 also apparently brought along the CQ revision of the CPU with it (http://www.emu-land.net/forum/index.php/topic,71921.msg1108836.html#msg1108836). There were also the later BQ and CQ steppings of the GPU, but I don't know if they have any other improvements or are recognized specifically by software.
Looks like you're right - I just checked the oldest boards I have here (which are PU-7) and they all have the same CXD8514Q GPU. The US ones have the same CXD8530BQ CPU as the image you posted - but the Japanese ones have an CXD8530AQ CPU chip instead. http://assemblergames.com/l/media/old-pu7.1591/ So it looks like the changes between A and B are not GPU related, but rather involve part of the CPU (GTE?). This was Sony's official statement about the changes: Let us inform you of some technical advise on further software development under the circumstance of the release of the Revision-C system. The Revision-C system is hardware where the graphics chips have changed. The main purpose of releasing the Revision-C system is to maintain stable memory supplies. Basically, it was designed under the concept with keeping full compatibility with current machine. However, there is a small difference between the Revision-C system and current models, Revisions A and B, as follows: (Revision A is a hardware for the Japanese market, and Revision B is a hardware for the US/European market. There is no problem of compatibility between Revisions A and B.) 1) Semi-transparent drawing is faster. An application which uses many transparent drawings runs faster. 2) It runs slower if vertically thin drawings or MoveImage() are frequently used. This will be obviously observed with thin rectangular regions that have a width of less than 16 dots.
It's pretty clear that Sony never wanted to waste a run of chips, they used up an earlier incompatible version of the GPU in arcade games (until they ran out and then they switched to standard ones). So it might be that B fixed issues with PAL. I've got a launch day scph-1002 somewhere (*), I'll check the chips it has. The DTL-H1002 still has the svideo ports, but I don't know if that means it predates the launch or not. I don't remember if they put manufacturing year/week on any of their chips. (*) I didn't buy it personally, but the person I got it from says it was and it definitely has the crappy chipset.
Sony parts normally have date codes - either the last two digits of the year followed by the week number or the last digit of the year followed by the week number. So the "9443" on that CPU on the PU-7 board I posted would be week 43, 1995. This is the oldest CPU I can find on any of the boards I have: 1994. week 27 - doesn't even have "Sony" and the Sony part number on it, just manufacturing markings and an indication that it's an "A" stepping part. http://assemblergames.com/l/media/old_cpu.1592/
So even the part number is the same between NTSC-J and NTSC-U early PU-7 boards (1-655-322-11), they just replaced the CPU with the BQ stepping. Pretty interesting that Sony's statement makes no mention of the improved dithering on Rev. C hardware... but if developers really did test their games on the green debugs, they would have probably noticed this change anyway.
Try Braidead 13 on a PS1 system with CXD8530AQ CPU. You're going to see some nice LCD trip going on. lol
I'm sure they did document it elsewhere, but the statement appears to be aimed at differences that would affect compatibility. There were also other changes between revisions that never had their functionality exposed by the libraries, so nobody noticed (off the top of my head the gpu status register added some extra bits that included dma status). Some of the changes only become relevant when you look at arcade games as they were either based on a different sdk, or the games hit the hardware to use functionality not exposed by the console sdk.
I've played on a console with the old GPU for the first time now after replacing the laser on my SCPH-1002, and it's quite remarkable how bad the old chipset really is in comparison. In Spyro 3 the banding is very noticeable right off the bat and the white smoke effect that appears when ramming sheep causes more slowdown on the SCPH-1002 as compared to the SCPH-5552. None of that being game-breaking of course, but it's interesting how these differences went without being widely documented for a long time. I did two comparison shots using an RGB CRT: [GALLERY=media, 1606]Spyro 3 SCPH-1002 old GPU by Xan01 posted Oct 1, 2016 at 8:41 AM[/GALLERY][GALLERY=media, 1607]Spyro 3 SCPH-5552 by Xan01 posted Oct 1, 2016 at 8:42 AM[/GALLERY]
I think they were talked about back in the day. However there are so many times you can say "it looks worse on older hardware" while the number of old PS1's got less and less over time.
I've noticed that datecodes don't seem to make much sense for the early CPUs. It seems that some early Japanese PU-7s have CXD8530Q CPUs, but the one on this image (https://imgur.com/a/DnHTS) has a 9507 datecode, which seems extremely late - apparently this revision had a cache bug and they even reworked boards with it to replace it with the AQ stepping, so it would seem strange that this chip would have been produced that late in time. TriMesh's CXD8530AQ (https://assemblergames.com/media/scph-1000-cpu.558/) has 9443, while the earliest CXD8530BQ I could find on the net has 9446 (https://imgur.com/MZaBye7). This CXD8530Q is also strange because its "0018" revision (?) number is even lower than this strangely marked CPU on TriMesh's devboard, which would match up with the AQ above: https://assemblergames.com/media/oldcpu.1798/ I wonder if this elusive CXD8530Q would show even more glitches in games compared to the AQ revision?
Yes, I noticed this as well. Basically there's something funny with PU-7 boards with chips with early 95 datecodes. I'd speculate that these are older, already manufactured chips, which got packaged into plastic later.
That could be possible - at least that chip really seems to stick out in color compared to the other ones.
Ah, nice! The game has regular MPEG decoding issues on my 2 PU-7 machines (one has the CXD8530Q and the other comes with the CXD8530AQ). Finally a retail game I know that has visible issues