[Hardware Mod] 8MB in (PU-18) Retail PSX

[Administrator]

Does this mod somehow improve the performance of the Playstation?

No. The only method of improving the performance is to increase the overall clock speed of the system.
Be careful though. Too fast and you will have instability and more heat.
Mind you, the games have already been optimised for the stock system specifications by Sony.

[stvincent]

So does changing the CPU clock affect the GPU clock as well?

TriMesh, have you looked into upgrading VRAM to 2MB? It should be feasible, because http://en.wikipedia.org/wiki/Namco_System_11 which is based on straight PS1 hardware had 2MB.

[nocash]

TriMesh, have you looked into upgrading VRAM to 2MB? It should be feasible, because http://en.wikipedia.org/wiki/Namco_System_11 which is based on straight PS1 hardware had 2MB.

That would be interesting, I don't even know how the GPU would address extra memory (at least some of the commands seem to be restricted to 1024x512 pixels; eg. the width/height parameters for VRAM Copy/Fill commands).

Btw. if I didn't misread my chipset part numbers... Samsung K4G163222A-PC70 (256Kx32x2)... then my PSone does have 2MByte VRAM installed, too (but uses only half of it, maybe because 2Mbyte chips became cheaper than 1Mbyte ones at time when the PSone was manufactured).
If there's really inactive 2MByte in the PSone, then it might be easy to mod that console without soldering too many pins.

On the other hand, if there's really 2MByte on System 11, then it might be inactive, too. Did anybody emulate that System 11, and knows more about its VRAM?

[TriMesh]

So does changing the CPU clock affect the GPU clock as well?

Not really - they have separate clocks (although on the PU-20 and later they are all derived from the same crystal) - in fact, it's slightly more complicated than this because part of the graphics pipe (the geometry transformation) is handed by a coprocessor built onto the main CPU die (the GTE) and sharing the same clock, so that will run faster with higher CPU clock speeds.

The GPU also has a dedicated clock signal, but this is used both to clock the internal logic and generate the video timing, so changing it will result in a video signal you probably won't be able to display. So overclocking the CPU will speed up the geometry calculations, but this will have no practical impact on most titles because they are render bound anyway.

There seems to be at least some of the internal logic on the GPU that runs from the NTSC reference clock even in PAL mode (at least, disabling this clock makes it lock up even if you have PAL selected) - so it's possible that you might be able to get it to run faster by overclocking the NTSC clock input while applying the correct clock to the PAL one - this hasn't been tested, though - and it will obviously only work in PAL mode.

TriMesh, have you looked into upgrading VRAM to 2MB? It should be feasible, because http://en.wikipedia.org/wiki/Namco_System_11 which is based on straight PS1 hardware had 2MB.

I have looked at it - but I never got around to doing anything with it. There is an extra chip select pin for the video memory on pin 121 of the GPU, so in theory you could piggy-back another SGRAM chip on top of the existing one and common all the pins except 28 - which would need connecting via a 22R series termination resistor to pin 121 on the GPU.

You would probably need to stuff the correct values into certain registers, too.

[Administrator]

That's very interesting NO$CASH. I wasn't aware that some PSone's had 2MB. You're right about the cheapness however. Another possibility is that the company stopped making 1MB VRAM chips, and by the time that happened, the PSone was at the end of its life so Sony didn't care.

Here are some photos of my System 12 (Tekken 3). Note the crystal oscillator speeds.
http://imgur.com/a/UzHjJ

[TriMesh]

TriMesh, have you looked into upgrading VRAM to 2MB? It should be feasible, because http://en.wikipedia.org/wiki/Namco_System_11 which is based on straight PS1 hardware had 2MB.

That would be interesting, I don't even know how the GPU would address extra memory (at least some of the commands seem to be restricted to 1024x512 pixels; eg. the width/height parameters for VRAM Copy/Fill commands).

Btw. if I didn't misread my chipset part numbers... Samsung K4G163222A-PC70 (256Kx32x2)... then my PSone does have 2MByte VRAM installed, too (but uses only half of it, maybe because 2Mbyte chips became cheaper than 1Mbyte ones at time when the PSone was manufactured).
If there's really inactive 2MByte in the PSone, then it might be easy to mod that console without soldering too many pins.

On the other hand, if there's really 2MByte on System 11, then it might be inactive, too. Did anybody emulate that System 11, and knows more about its VRAM?

No, you didn't misread the datasheet -it really is a 2MB part, but on the PSone pin 30 (A8) is connected to ground, A9 (pin 51) is connected to A8 and pin 29 (A10/BA0) is connected to A9, so you can only access half of it. Note that this is an intentional design feature of the chip - it was pinned out so that it would be connected this way if placed on a board that was laid out for the old 1M 1024 x 256 x 32 bit SGRAM.

[smf]

On the other hand, if there's really 2MByte on System 11, then it might be inactive, too. Did anybody emulate that System 11, and knows more about its VRAM?

Yes, over a decade ago. Early System 11 boards have a very different GPU (CXD8538Q) that has different encodings for commands and textures can be scrambled (probably to improve ram performance), they were produced before the console. Later System 11 boards used GPUs from consoles (CXD8561Q) but still with 2mb of vram.

The GPU definitely does a lot of it's calculations in 1024x1024, but anything in lines 512-1023 wrap to line 0-511 if you only have 1mb. Also note the extra texture y bit in tpage:

Code: Select all

f  e| d  c| b| a  9| 8  7| 6  5| 4| 3  2  1  0
    |iy|ix|ty|     |   tp|  abr|ty|         tx

The arcade and console GPU's may have diverged later and support for 2mb of vram dropped from the console, but I could really do with a list of all the consoles/motherboards/chip numbers to be able to help further as I only have a list of what was used on the arcade boards.

[TriMesh]

The arcade and console GPU's may have diverged later and support for 2mb of vram dropped from the console, but I could really do with a list of all the consoles/motherboards/chip numbers to be able to help further as I only have a list of what was used on the arcade boards.

It's a very short list

PU-7 and -1x PU-8s used the CXD8514Q
Everything from the -2x PU-8 to the early PSones used CXD8561[ABC]Q
The later PSOnes used another part that I can't remember the P/N for that had the SGRAM in the package.

[Administrator]

That reminds me, I swapped out VRAM from a SCPH-102 (PSone) and put it in a SCPH-7502 (PSX). I should have checked it to see whether it was 2MB or not. It worked perfectly fine anyhow. Reason for the swap was the 7502 would only display a white screen, and that means it's fried.

[smf]

PU-7 and -1x PU-8s used the CXD8514Q
Everything from the -2x PU-8 to the early PSones used CXD8561[ABC]Q
The later PSOnes used another part that I can't remember the P/N for that had the SGRAM in the package.

I've not seen the CXD8514Q used with 2mb of vram, but anything with a CXD8561[ABC]Q should be fine.

It's possible there will be some compatibility issues though if you do upgrade, but then there are some issues with upgrading to 8mb as well.

Do you have a list of the other chips used on each motherboard (CPU/GPU/SPU/CD chips/bios etc) and what they were sold as (SCPH etc)?

[TriMesh]

PU-7 and -1x PU-8s used the CXD8514Q
Everything from the -2x PU-8 to the early PSones used CXD8561[ABC]Q
The later PSOnes used another part that I can't remember the P/N for that had the SGRAM in the package.

I've not seen the CXD8514Q used with 2mb of vram, but anything with a CXD8561[ABC]Q should be fine.

It's possible there will be some compatibility issues though if you do upgrade, but then there are some issues with upgrading to 8mb as well.

Do you have a list of the other chips used on each motherboard (CPU/GPU/SPU/CD chips/bios etc) and what they were sold as (SCPH etc)?

I haven't really got a list, but I can tell you what I can remember:

CPUs:

PU-7, PU-8 up to and including -2x: CXD8530[AB]Q
Later PU8s, etc: CXD8606[AB}Q

SPU:

PU-7: CXD2922Q
PU-8, PU-18, PU-20: CXD2925Q
PU-22, PU-23, PSone: in CXD2938Q

CD Subsystem (DSP / Decoder)
PU-7: CXD-2516BQ/CXD1199BQ
PU-8: CXD-2510Q/CXD1815Q
PU-18: CXD2545Q/CXD1815Q
PU-20: CXD1817R (both in one chip)
PU-22, PU-23, PSone: CXD2938Q (with SPU)

DAC/Video encoder
PU-7, -1x PU-8: CXD1923AR / CXA1645
-2x PU-18, PU-18: MC141685FT or TDA8771 / CXA1645
PU-20, PU-22, PU-23, PSone: BH7440AKV or equiv (There is a CXAxxxx Sony version)

Clocking:
PU-7, PU-8, PU-18 use separate CPU and GPU oscillators
PU-20, PU-22, PU-23, PSone use a clock PLL and a single xtal

There are some other parts that were used in the later PSones, but they were mostly moving RAM into other chips.

[smf]

PU-7, PU-8 up to and including -2x: CXD8530[AB]Q
Later PU8s, etc: CXD8606[AB}Q

There is a CXD8606CQ used on later Namco System 10 boards, I don't know if that turned up in any consoles. Games were still being released in 2003.

Confusingly Namco System 12 predated System 10, the first of those boards had a unique set of CPU (CXD8661R) & GPU (CXD8654Q) with 2mb of vram and 4mb of main ram. Then they switched back to CXD8606BQ & CXD8561CQ and attached them to 4mb of vram and 16mb of main ram (how much of it is usable is another matter).

I believe the cpu on all of these was clocked at approximately 50mhz.

[nocash]

Also note the extra texture y bit in tpage

Didn't knew about that bit. From my own tests (on a PSone), bit13 bit11 did disable textures... which might be actually happening due to issuing a chipselect to an absent VRAM chip... and then, it seems to be still supported on PSone's.

According to how it's used by PSX software, the bit is also related to the GPU version, and to GP1(09h) command, so maybe it isn't supported on all GPUs, and/or there might be different modes (like two chipselects, or alternately one extra address line).

[smf]

Didn't knew about that bit. From my own tests (on a PSone), bit13 did disable textures... which might be actually happening due to issuing a chipselect to an absent VRAM chip... and then, it seems to be still supported on PSone's.

It's difficult to be confident as you don't say what GPU you tested with, but I've only seen CXD8561 and CXD8654 used with 2mb of vram.

I don't know how you're labelling your bits, but that seems to tie up with one of the invert texture bits used by sprites. It might disable textures when using quads, or there might be something more interesting going on. If you invert sprites you have to change the coordinates to the opposite edge of the texture or the rendering is broken. The disabling of textures might be a side effect of setting that bit and passing incorrect texture coordinates.

On the gpu used on the early arcade games the tpage register was very different and what I would call bit 13 would enable the texture scrambling. There might be left over code that is checking for the gpu version and then enabling that. The arcade version of Tekken does this but it doesn't work properly if it finds the later gpu as parts of the game are hard coded to expect an old gpu, the game may predate the libraries and just had them grafted on at a late stage.

The old gpu supports screen flipping along the x axis and has lightgun support builtin, read by gpu info 0x08

The x axis flipping appears to have made it into http://psx.rules.org/gpu.txt, the "Reverseflag".

*Display mode
command $08
parameter bit $00-$01 Width 0
bit $02 Height
bit $03 Videomode See above
bit $04 Isrgb24
bit $05 Isinter
bit $06 Width1
bit $07 Reverseflag

I assume the documentation for this came from some prelease information. I heavily suspect the DTL-H500 target box gpu is similar to the old arcade one. I don't think this flag does anything on any console hardware, but I could be wrong......

[TriMesh]

PU-7, PU-8 up to and including -2x: CXD8530[AB]Q
Later PU8s, etc: CXD8606[AB}Q

There is a CXD8606CQ used on later Namco System 10 boards, I don't know if that turned up in any consoles. Games were still being released in 2003.

Confusingly Namco System 12 predated System 10, the first of those boards had a unique set of CPU (CXD8661R) & GPU (CXD8654Q) with 2mb of vram and 4mb of main ram. Then they switched back to CXD8606BQ & CXD8561CQ and attached them to 4mb of vram and 16mb of main ram (how much of it is usable is another matter).

I believe the cpu on all of these was clocked at approximately 50mhz.

I think I might have seen that C stepping part in some of the later PSones, but it's not on any of the boards I have here.

My guess is that they first produced the arcade systems, they had to make a special chip because they needed the extended memory addressing, and it wasn't in the silicon that was designed for the retail console.

Later, when they were designing the new chips, it made sense to design one chip that was usable for both the retail and arcade systems, since at that point they already knew what the feature set for both needed to be. That also explains why the 8606 has an extra RAS line that's not used in any retail console and the 8561 has two VRAM chip selects, although the console only has one memory chip - it was added to the design to support it's use in the arcade machines.

It's interesting that it has 4MB of video RAM - in my experience, most SGRAM has 256 columns, and the CXD8516 only has a 10 bit address bus - which with 32 bit words would limit you to 1MB per chip select - do you know what the part number for the SGRAMs used on the arcade board is? I guess it's possible that they found a 512 column part and there is some hidden mode bit in there that lets you use it, since that would allow the use of 4MB of RAM.

On the CXD8606, the most I could get it to address was 8MB - there is a mode that enables both RAS lines, but that seems designed to work with 4MB of RAM (2 MB for RAS0, 2 MB for RAS1, and it pulls a bus fault on the second 4MB). Are there any schematics or even good photos of the arcade boards?

[nocash]

bit13 did disable textures...

I don't know how you're labelling your bits

Oops, sorry, I was mislabling it. What I meant was Bit 11 (or bit "b", counted in hex, as you labled it).

Texture flipping is per-sprite attribute (in Texpage), theoretically there should be no relation to "Reverseflag" (in Display Mode register), or did older GPUs have that bit related to flipping? Or did you mean SCREEN xflip, not texture xflip?

On PSone PAL, the "Reverseflag" bit affects how to handle color clock mismatches (in relation to the dotclock). Either static PAL artifacts at fixed location, or, by default and less ugly: flimmering artifacts at different locations in each frame. For RGB it should have no effect (apart from affecting the frame length). Does it work like so on NTSC and on older GPUs, too?

[smf]

Or did you mean SCREEN xflip, not texture xflip?

Yes the whole screen could be flipped horizontally, a lot of arcade hardware allows this as you can mount the monitor in the bottom of the cabinet facing up and then have a mirror reflecting the image. Like sprite flipping you had to change the display start, it doesn't calculate it for you.

I haven't done any tests but as the original console gpu doesn't have sprite flipping, I guess the original arcade gpu that has screen flipping doesn't have sprite flipping either. I have a board that uses an eprom to boot, so at some point I might hack up some form of interface to allow software to be downloaded from a pc.

On PSone PAL, the "Reverseflag" bit affects how to handle color clock mismatches (in relation to the dotclock). Either static PAL artifacts at fixed location, or, by default and less ugly: flimmering artifacts at different locations in each frame. For RGB it should have no effect (apart from affecting the frame length). Does it work like so on NTSC and on older GPUs, too?

Does that affect interlace and non-interlace modes? It sounds to me like the difference in artifacting is a side effect of it doing something else. I haven't done any tests other than trying to see if it flipped the screen, I always use RGB anyway.

[Administrator]

Okay, the SGRAM moved from my 102 to a 7502 (PU-20 -22) is a SAMSUNG K4G163222A-PC70.
"256K x 32Bit x 2 Banks Synchronous Graphic RAM".

http://datasheet.octopart.com/K4G163222 ... 924935.pdf

[gwald]

First of all, many thanks to Shadow for humoring me when I hassled him to do wiring checks on his DTL-H2000. It might have been possible to do this mod without that information, but it would certainly have been far more difficult.

This is an excellent through, very cool that you figured out how to do it, and then do it

The DRAM chips, are they still being made?
Is it these? http://angrand.en.alibaba.com/product/6 ... 4AJ_6.html

Also, if someone was to develop something epic using 8megs!!!
And burn it to iso, it would most likely run on a software emulator right?

[Alexander_H]

Hi,

i have a little trouble with my Memory-expansion. For this Project, i used Memory Chips from a 16 MB EDO-DIMM 144-pin Laptop-Memory 3.3V 60 ns 'Samsung KMM466F213BS1-L6' . The two Playsis running same without Problems after the upgrade, but the Ramtest V2 loosing the Caetla connection. may i took something wrong ??? ^^"

I tested again and find out, that i run in trouble, if i touch with the ramtest in the last area of the ram.
If i #define STACKSLACK 0x12800 it will mostly run, but sometimes Caetla crashing