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

[TriMesh]

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.

The question of if it's possible to upgrade the RAM on a retail to be the same as the devboard has been raised a number of times, and the answer is yes, it is.

The required modification is purely hardware - you don't need a new BIOS, since the software support is already in there. The main restriction is that you require certain specific models PSX with a PU-18 main board (the ones with 4 RAM chips) to do this. It should be theoretically possible to do it on the 4-chip PU-7s and PU-8s too - but this has not actually been tested.

The short version of the mod is that you have to take off the existing RAM, and solder in 4x KM48V2104AJ-6 chips, then cut traces and do some rewiring on the back of the board. For the full details, see the attached .pdf

[Shendo]

Awesome, nice guide.
Does your memory test work on retail units too?
I mean does it detect available memory and then tests it or it's for 8MB machines only?

[TriMesh]

It will refuse to run on a 2MB unit - the problem is that on a regular PSX the 2MB memory is mirrored 4 times - so if you try writing to memory above 2MB it will trash all the BIOS data in the machines low memory. This makes it ... unhappy.

It's pretty quick and dirty anyway - but I'm sure it could be hacked to test other memory areas.

Code: Select all

//
// Quick and dirty RAM test for the 8MB expansion.
//
//  Fills the memory area between 2MB and 8MB with a pseudo random pattern
//  then reads it back and verifies that the contents match.
//
//  The fill pattern is constructed by XORing each byte in the address
//  together, then XORing the result with a constant.
//
//  Since this code overwrites everything in the upper 6MB of RAM, it
//  has to be run with an execution enviroment that doesn't try to put
//  any useful data there - most noticably, the stack can't be at the 
//  top of physical memory and has to be below 2MB.  This ia a safe
//  assumption to make using the Yaroze toolchain, but if you are running
//  this code using the devkit build tools make sure you link it for
//  a 2MB system.
//

// Pull in the Yaroze library
#include <libps.h>

// Initial expansion RAM address
#define STARTADDR 0x80200000
// Final expansion RAM address + 1
#define ENDADDR 0x80800000

// Salt values to use for each pass
unsigned char salts[] = { 0x00, 0xFF, 0x55, 0xAA, 0x33, 0xCC };
#define NUMSALTS (sizeof(salts) / sizeof(salts[0]))

// RAM test
void main (void)
{
	unsigned int addr, pass, testval;
	unsigned char value;
	unsigned char *testptr;
	printf("\nTesting expanded RAM...\n");
	
	// Start off by verifying that we are possibly on a 8MB system
	// This test is necessary because on a regular retail PSX the
	// area we are writing to is aliased to the standard 2MB - so
	// writing pseudorandom data to it will make the system crash
	// almost instantly.  So we won't do it.
	printf("RAMTEST: Performing RAM aliasing check\n");
	testval = 0xaa55a55a;		// Set a known value
	testptr = (unsigned char *) &testval;  // Get the pointer to the variable
	testptr += 0x200000;					// Point to the same location 2MB up
	*((unsigned int *)testptr) = 0xdeadbeef;
	testptr += 0x200000;					// Another 2MB up
	*((unsigned int *)testptr) = 0xdeadbeef;
	testptr += 0x200000;					// Another 2MB up
	*((unsigned int *)testptr) = 0xdeadbeef;

	// Did any of these writes step on our variable?
	if (testval != 0xaa55a55a) {
		printf("RAMTEST: RAM aliasing test failed.  Aborting.\n");
		return;
	}
	printf("RAMTEST: Aliasing test passed, continuing.\n");
	
	// Do multiple passes of the memory with different values each time
	for (pass = 0; pass < NUMSALTS; pass++) {
		printf("RAMTEST: Pass %d (salt value 0x%02x)\n", pass + 1, salts[pass]);	
		printf("RAMTEST: Filling RAM\n");
		for (addr = STARTADDR; addr < ENDADDR; addr++) {
			value = (addr ^ (addr >> 8) ^ (addr >> 16) ^ (addr >> 24) ^ salts[pass]) & 0xff;
			*((unsigned char *)addr) = value;
		}
		
		// Simulate a fault to check the diagnostic message
//		*((unsigned char *) 0x80315ee9) = 0x34;
		
		printf("RAMTEST: Verifying\n");
		for (addr = STARTADDR; addr < ENDADDR; addr++) {
			value = (addr ^ (addr >> 8) ^ (addr >> 16) ^ (addr >> 24) ^ salts[pass]) & 0xff;
			if (*((unsigned char *)addr) != value) {
				printf("RAMTEST: Verify failure at 0x%08x - expected 0x%02x, got 0x%02x\n", addr, value, *((unsigned char *)addr));
				return;
			}
		}
	}
	printf("RAMTEST: Testing completed OK\n");
	return;
}

[Administrator]

Thanks for the credit TriMesh
I quickly made up a Psy-Q project for others as the code above is for the Yaroze SDK.

RAMTEST.zip

[Yuri^Cybdyn]

this thing is something unbelievable for me, but if you understand what to do - you get real result. I'm impressed!

[TriMesh]

this thing is something unbelievable for me, but if you understand what to do - you get real result. I'm impressed!

I left some of the technical details out because this was a "how to" - but you might be interested in them.

First of all, I didn't think it was going to work, either - the biggest problem was that the devices have multiplexed address buses and a different number of row addresses - which would normally end up making at least part of them inaccessible.

But against this, the same CPU that's used in the PU-7 was also used on the DTL-H2000 - and that CAN support 8MB - and there is no sign of a memory controller mode bit in any of the registers. So I got the scope out and started poking around on the board, and quickly worked out exactly what Sony had done.

Even on a retail using the 512KB chips with 1024 row addresses the address multiplexing is done as if the RAM has 2048 rows - so the RAM A0 pin gets A0 during RAS and A11 during CAS - since the actual chips only have 1024 row addresses, this would cause every 4K block (since these are word addresses) of the RAM to be repeated twice - so Sony cheated and created a special signal (output on the A11 pin of the CPU) that got A8 during RAS and A10 during CAS. A9 can be used as-is, since the 512KB devices only have 512 column addresses and hence the value of the A9 pin during CAS time doesn't matter.

This also finally makes sense of the strange way that A8 is connected on retail units - it's a hack to get around the fact that the memory controller really doesn't support 1024 row memory.

[TriMesh]

I discovered that the default Caetla setup sets the initial SP to 8MB - this is normally harmless because of the memory aliasing, but it means that the memory test blows up when you try to run the memory test under Caetla.

This is a fixed version that relocates the stack.

Code: Select all

//
// Quick and dirty RAM test for the 8MB expansion.
//
//  Fills the memory area between 2MB and 8MB with a pseudo random pattern
//  then reads it back and verifies that the contents match.
//
//  The fill pattern is constructed by XORing each byte in the address
//  together, then XORing the result with a constant.
//
//  Since this code overwrites everything in the upper 6MB of RAM, it
//  has to be run with an execution enviroment that doesn't try to put
//  any useful data there - most noticably, the stack can't be at the 
//  top of physical memory and has to be below 2MB.  This ia a safe
//  assumption to make using the Yaroze toolchain, but if you are running
//  this code using the devkit build tools make sure you link it for
//  a 2MB system.
//

// Pull in the PSX library
#include <libsn.h>

// Space to reserve for stack at top of RAM
#define STACKSLACK 0x1000
// Initial expansion RAM address
#define STARTADDR 0x80200000
// Final expansion RAM address (avoid smashing stuff..)
//#define ENDADDR 0x80800000-STACKSLACK
#define ENDADDR 0x80800000

// Salt values to use for each pass
unsigned char salts[] = { 0x00, 0xFF, 0x55, 0xAA, 0x33, 0xCC };
#define NUMSALTS (sizeof(salts) / sizeof(salts[0]))

// Memory mapping types
char *maptypes[] = {
	"1MB / 7MB inval (000)",
	"4MB / 4MB inval (001)",
	"1MB / 1MB HiZ / 6MB inval (010)",
	"4MB / 4MB HiZ (011)",
	"2MB / 6MB inval (100)",
	"8MB (101)",
	"2MB / 2MB HiZ / 4MB inval (110)",
	"8MB (111)"
};

// RAM test
int main (void)
{
	unsigned int addr, pass, testval, stkptr, newstk, ramctl;
	unsigned char value;
	unsigned char *testptr;
	printf("\nTesting expanded RAM...\n");
	asm ("or\t%0,$sp,$0\nlui\t$sp,0x801f\nor\t$sp,0xff00\n":"=r"(stkptr));		// Get the stack pointer value
	asm ("or\t%0,$sp,$0\n":"=r"(newstk));
	printf("\nRAMTEST: SP value was 0x%08x, is 0x%08x\n", stkptr, newstk);
	// Force map type to 2MB - this will cause a bus error during the aliasing check...
//	*((unsigned int*)0x1F801060) = 0x00000888;
	
	// Get the RAMCTL value
	ramctl = *((unsigned int*)0x1F801060);
	printf("RAMTEST: MEMCTL=0x%08x (Map Type = %s)\n", ramctl, maptypes[(ramctl >> 9) & 0x7]);
		
	// Start off by verifying that we are possibly on a 8MB system
	// This test is necessary because on a regular retail PSX the
	// area we are writing to is aliased to the standard 2MB - so
	// writing pseudorandom data to it will make the system crash
	// almost instantly.  So we won't do it.
	printf("RAMTEST: Performing RAM aliasing check\n");
	testval = 0xaa55a55a;		// Set a known value
	testptr = (unsigned char *) &testval;  // Get the pointer to the variable
	testptr += 0x200000;					// Point to the same location 2MB up
	*((unsigned int *)testptr) = 0xdeadbeef;
	testptr += 0x200000;					// Another 2MB up
	*((unsigned int *)testptr) = 0xdeadbeef;
	testptr += 0x200000;					// Another 2MB up
	*((unsigned int *)testptr) = 0xdeadbeef;

	// Did any of these writes step on our variable?
	if (testval != 0xaa55a55a) {
		printf("RAMTEST: RAM aliasing test failed.  Aborting.\n");
		printf("RAMTEST: Jumping back to BIOS\n");
		((void(*)(void))0xbfc00000)();
	}
	printf("RAMTEST: Aliasing test passed, continuing.\n");

	// Do multiple passes of the memory with different values each time
	for (pass = 0; pass < NUMSALTS; pass++) {
		printf("RAMTEST: Pass %d (salt value 0x%02x)\n", pass + 1, salts[pass]);	
		printf("RAMTEST: Filling RAM\n");
		for (addr = STARTADDR; addr < ENDADDR; addr++) {
			value = (addr ^ (addr >> 8) ^ (addr >> 16) ^ (addr >> 24) ^ salts[pass]) & 0xff;
			*((unsigned char *)addr) = value;
		}
		
		// Simulate a fault to check the diagnostic message
//		*((unsigned char *) 0x80315ee9) = 0x34;
		
		printf("RAMTEST: Verifying\n");
		for (addr = STARTADDR; addr < ENDADDR; addr++) {
			value = (addr ^ (addr >> 8) ^ (addr >> 16) ^ (addr >> 24) ^ salts[pass]) & 0xff;
			if (*((unsigned char *)addr) != value) {
				printf("RAMTEST: Verify failure at 0x%08x - expected 0x%02x, got 0x%02x\n", addr, value, *((unsigned char *)addr));
				printf("RAMTEST: Jumping back to BIOS\n");
				((void(*)(void))0xbfc00000)();
			}
		}
	}
	printf("RAMTEST: Testing completed OK\n");
	printf("RAMTEST: Jumping back to BIOS\n");
	((void(*)(void))0xbfc00000)();

	return;		// Never executed, but should keep the compiler happy
}

[danhans42]

Great work TriMesh, can you recommend a good source for the RAM chips? Only place I can find is in the USA at they have a $200 minimum order.

[TriMesh]

Great work TriMesh, can you recommend a good source for the RAM chips? Only place I can find is in the USA at they have a $200 minimum order.

I got them from one of the suppliers in Shenzhen that deals with obsolete parts - they were not that easy to find, and took a couple of days to turn up. I would offer to send you some, but I only have 2 left (I got 10 of them and modified the 2 PU-18s I have here). The next time I'm there, I will grab a copy of the guy's business card and give you the details - I should warn you that his English is really bad, though

[AmiDog]

Hmm, are we talking about these RAM chips?

[danhans42]

@Trimesh - Cheers, I have since found a company via Alibaba called Winsource that have them @$1.87ea plus $20 for freight shipping to UK.

@Amidog - Not sure, I wonder if the difference between the 00 and 04 is in the model number.

[TriMesh]

Hmm, are we talking about these RAM chips?

Sadly, they won't work - the first thing is that they are "KM48C" rather than "KM48V" - so they are designed to operate from 5V rather than 3.3V. The second is that the '0' at the end indicates that they are fast page mode devices - and the PSX memory controller is designed to work with EDO chips. For reference, you can't use the KM48V2004AJ-6 either - it has 4096 row addresses, and the PSX memory controller doesn't support that.

In fact, the only other part I found that seemed to be compatible was from NEC - and nobody seemed to ever had had it in stock - I assume it must have existed, since it was listed in an old NEC shortform catalog, but nobody that I could find ever seems to have actually used it.

[danhans42]

The person I have on alibaba is getting back to me with a price for 24. Looking around £40 ish delivered.

So when I get them I'll see about selling on the leftovers if anyone else wants any?

EDIT: 24 units ordered. Hopefully should be here in a week or two.

[Myria]

I'm going to guess that going from 8 to 2 MB RAM for retail units was a late decision in the design of the PSX. It'd explain the use of a hack, but isn't conclusive.

This is kind of like how the SNES probably had 128 KB of VRAM until late in design they dropped it to 64 KB. The SNES VRAM was word-addressed, as 32Kx16. However, the control registers containing VRAM addresses--even ones with only partial addresses--seemed to always have an extra reserved bit. Wonder why... (Dev on SNES didn't have extra VRAM. I've never heard of dev SNES's existing past the release of the SNES, but I am not one to consider an expert on SNES.)

[TriMesh]

I'm going to guess that going from 8 to 2 MB RAM for retail units was a late decision in the design of the PSX. It'd explain the use of a hack, but isn't conclusive.

This is kind of like how the SNES probably had 128 KB of VRAM until late in design they dropped it to 64 KB. The SNES VRAM was word-addressed, as 32Kx16. However, the control registers containing VRAM addresses--even ones with only partial addresses--seemed to always have an extra reserved bit. Wonder why... (Dev on SNES didn't have extra VRAM. I've never heard of dev SNES's existing past the release of the SNES, but I am not one to consider an expert on SNES.)

It is a hack, but it's a hack that's built into the silicon - and it seems to have been present even on the engineering sample chips. This does suggest that the capability to support 2MB (or, more precisely, support DRAM with 1024 refresh cycles) was included as an early design requirement.

The other reason I think it was unlikely they planned to release the retail unit with 8MB is simply cost - when the PSX was designed, the predominant DRAM technology was fast page mode - but Sony decided to go with Hyper page (AKA EDO) RAM for the main system memory and dual-port VRAM for the video memory. Both of these technologies were around, but they weren't mainstream and they were quite expensive. My guess is that even buying in vast quantities that 2MB of EDO RAM was costing them something like $40-$45, and was likely the most expensive single line on the BOM. Since they were apparently selling at a small loss already to hit their price point, I doubt they would have been willing to swallow another $120-$130 in parts costs.

As it turned out, Sony made a good call with this - EDO did become the mainstream memory, and it also became very cheap, hence the ability to sell the PSX at $99 and the end of it's run (and apparently actually make money on it at this price...). The VRAM ended up being not such a great choice, since it never became really mainstream (hence the change to SGRAM on the later machines).

[Greg]

@TriMesh

in the "PU-18 RAM mod.pdf" file in the "Parts and tools required" section you mention that 4 x KM48V2105AJ-6 are required, may I assume it's a typo?

[TriMesh]

@TriMesh

in the "PU-18 RAM mod.pdf" file in the "Parts and tools required" section you mention that 4 x KM48V2105AJ-6 are required, may I assume it's a typo?

Well, spotted - yes, that was a typo - the correct P/N is KM48V2104AJ_6

RAMChips.jpg

[Gradius]

Very nice mod and simple, but it would be useful to report which SCPH models has (or uses) a PU-18 ?

[TriMesh]

Very nice mod and simple, but it would be useful to report which SCPH models has (or uses) a PU-18 ?

Best bets are SCPH-5500, SCPH-5501, SCPH-5502 and SCPH-5552. If you have a SCPH-700x machine then it's worth checking because the early production used the PU-18, although most of them are PU-20.

There is also a single RAM chip variant of the PU-18 board, and that won't work for this mod - in my experience they are quite uncommon, though.

[art_m11]

Does this mod somehow improve the performance of the Playstation?