Greetings everyone,
I have decided to attempt an 8MB RAM mod on a PU22, not because I lack PU18 units, but just for fun and experimentation.
Given that the PU22 uses a single 2MB DRAM IC, I decided to build a small flexible board to be soldered in place of the IC, with pads to solder the same DRAMs used to mod the PU18.
A8 and A10 are taken directly from the CPU, A11 is left disconnected, and everything else is wired as shown in the PDF.
I mounted KM48V2104ALT-6 DRAM ICs, and soldered the PCB to the PU22. Surprisingly, the board boots, and plays games just fine, but when I try to access extra ram using UNIROM and the /dump and /poke commands, I can see the memory is still mirrored every 2MB, so something is still amiss.
At this point I'm beginning to suspect that the BIOS on this PU22 (md5: b9d9a0286c33dc6b7237bb13cd46fdee) might not support 8MB correctly.
Does anyone know if the 8MB support was ever removed from a certain version onward? (and, just in case, any idea which type of (E)EPROM can be used to replace a PS1 BIOS?
Or maybe I just forgot to disconnect (or connect) something, but can't really spot any error in that regard.
[Hardware Mod] Attempting 8Mb mod on PU22
[Hardware Mod] Attempting 8Mb mod on PU22
You do not have the required permissions to view the files attached to this post.
Are you aware of the relevant stuff, like
and
Code: Select all
1F801060h 4/2 RAM_SIZE (usually 00000B88h; 2MB RAM mirrored in first 8MB)
Code: Select all
A(9Fh) - SetMemSize(megabytes)
Yep, no idea if I'm setting them wrong, but here is what I get with
So the RAM_SIZE doesn't seem to update, and the data is still mirrored.
EDIT: The value at 0x00000060 gets updated to 8 though.
Code: Select all
ResetCallback();
AddSIO(115200);
printf("RAM_SIZE before 0x%04X\n", *(volatile uint16_t*)(0x1F801060));
SetMem(8);
printf("RAM_SIZE after 0x%04X\n", *(volatile uint16_t*)(0x1F801060));
*(volatile uint8_t*)(0x80200000) = 0x22;
*(volatile uint8_t*)(0x80300000) = 0x33;
*(volatile uint8_t*)(0x80400000) = 0x44;
*(volatile uint8_t*)(0x80500000) = 0x55;
*(volatile uint8_t*)(0x80600000) = 0x66;
*(volatile uint8_t*)(0x80700000) = 0x77;
printf("Test 0x%02X\n", *(volatile uint8_t*)(0x80200000));
printf("Test 0x%02X\n", *(volatile uint8_t*)(0x80300000));
printf("Test 0x%02X\n", *(volatile uint8_t*)(0x80400000));
printf("Test 0x%02X\n", *(volatile uint8_t*)(0x80500000));
printf("Test 0x%02X\n", *(volatile uint8_t*)(0x80600000));
printf("Test 0x%02X\n", *(volatile uint8_t*)(0x80700000));
Code: Select all
RAM_SIZE before 0x0B88
Change effective memory : 8 MBytes
RAM_SIZE after 0x0B88
Test 0x22
Test 0x33
Test 0x66
Test 0x77
Test 0x66
Test 0x77
EDIT: The value at 0x00000060 gets updated to 8 though.
Woot!
Found the issue! I swapped A8 with A10, and now I get the whole 8MB, test is passing too!
Great, I will cleanup a few things then release everything so others can perform the same mod on their PU22 too.
Found the issue! I swapped A8 with A10, and now I get the whole 8MB, test is passing too!
Code: Select all
Stack = 807FE000
Test the PlayStation RAM
Original code by Trimesh
Generating fill pattern...
0x80200000
0x80210000
0x80220000
0x80230000
0x80240000
0x80250000
...
0x807A0000
0x807B0000
0x807C0000
0x807D0000
0x807E0000
0x807F0000
Verifying fill pattern...
0x80200000
0x80210000
0x80220000
0x80230000
0x80240000
0x80250000
0x80260000
0x80270000
0x80280000
...
0x80770000
0x80780000
0x80790000
0x807A0000
0x807B0000
0x807C0000
0x807D0000
0x807E0000
0x807F0000
Success! 8 MB RAM Test *PASSED*
There, mod released, I closed up my SCPH-7502 and played around with it for a day. Still working fine, games still running, all RAM still addressable.
Hope someone else can have fun with it: PS1_PU22_8MB_mod
You will need moderate soldering skills, nothing too hard here, but a steady hand is a must.
Hope someone else can have fun with it: PS1_PU22_8MB_mod
You will need moderate soldering skills, nothing too hard here, but a steady hand is a must.
You do not have the required permissions to view the files attached to this post.
-
Administrator Verified
- Admin / PSXDEV
- Posts: 2691
- Joined: Dec 31, 2012
- I am a: Shadow
- PlayStation Model: H2000/5502
I wonder how many bytes will get corrupted overtime due to the RAM being mounted on a giant antenna 

Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.
Yup, I was actually very wary of building the adapter this way exactly for potential corruption/noise/crosstalk issues, but I decided to try nonetheless.Administrator wrote: ↑September 1st, 2024, 2:44 pm I wonder how many bytes will get corrupted overtime due to the RAM being mounted on a giant antenna![]()
The biggest problem, I thought, was the long section where data and address lines are by side for a significant distance before they reach a zone with a ground plane.
Surprisingly, even checking with a scope, I couldn't find significant degradation (compared to another, untouched, PU-22), nor could I detect instability after running the console for hours with a game on.
Note that the RAM board is mounted between two shields, and is directly grounded on one of the two.
Who is online
Users browsing this forum: No registered users and 9 guests