@akuhak There might be a way of identifying EE chips down to their exact chip number (in case you are interested) :
Code:
0x1000F000 0x1000F0FF INTC
0x1000F100 0x1000F1FF SIO
0x1000F200 0x1000F2FF SIF
0x1000F300 0x1000F3FF PGIF
0x1000F400 0x1000F4FF RDRAMC
0x1000F500 0x1000F5FF Memory Controller most likely NOT: DMAC Special - for pausing & most likely RAM and other devices configuration - register 0x1000F500 is written 0xFFFFFFFF in some (later) RESET versions, while it is written 0x1 in earlier.
0x1000F600 0x1000F6FF LSWord C0019600 00000008 00000000 00000000 MSWord is returned for each qword(when read as 32-bit words) in this range. Write has no effect, but this might be only in some conditions.
0x1000F700 0x1000F7FF LSWord 00000200 00000000 00000000 00000000 MSWord.
F400 is RDRAM Controller.
F500 contains the registers for suspending and resuming DMA. However this range seems to actually contain general EE-management registers.
Here is a brief description:
F500 - written in RESET with 1 and on models after ~ SCPH-50000 with -1 (0xFFFFFFFF). Only bits 0 and 1 are read-writable. I believe this enables the EE TLB, but have yet to prove this.
F510 - written in the EE KERNEL when (just before) initializing VU0. Most likely it controls the EE Core <-> VU0 coprocessor connection. Many bits are writable and affect the value read from F590 as well.
F520 bit 16 is the DMAC-suspend bit (when set) but bits 23:16 are all writable. (Actually F590 has to be written, as this is a read-only access to F590.)
Bits 15:0 here are interesting and the reason for this message. They are read by the RDRAM program in order to configure the RDRAMC, but the value they contain commonly matches the EE revision. See below.
F530 r/o mirror of F520
F540, F550 - contain the same values on multiple resets and program execution. I think these are some revision numbers. Because I don't have two identical PS2 models, I can't tell if they change between the same models, but most likely they don't. I can't find any pattern between these and the chip number.
Code:
F520 F540 F550 EE chip
0000210C 0019C882 002848E0 CXD9615GB (SCPH-30003)
00003101 00480812 0090C410 CXD9708GB EE only / CXD9832GB EE only (I am not sure which one) (SCPH-70004)
00004322 10497626 00150808 CXD2976GB EE+IOP+... (SCPH-79004)
It is not impossible that F540, F550 are numbers signifying the manufacturing batch.
F560, F570 - always 0. Might be unused extension to F540, F550.
F580 - unknown. Bits 3:0 are read-writable.
F590 - See F520. The value read from 23:8 depends on what was written to F510. The value in 7:0 changes on every few reads randomly, but usually between values in close range. The values read might just be unimplemented.
F5A0 - F5F0 - read-only mirrors of F580 and F590.
The RDRAM program from SCPH-90000 contains a table with the following values, which it compares with the value read from F520:
Code:
value corresponding EE revision
0x1201 none such, but there is 1.4 in the PS2Ident database
0x2000 2.0, but most likely EE PRId can report rev. 2.0 for all of these 0x20XX - 0x21XX
0x2101
0x2002
0x2102
0x2104
0x210C
0x210F
0x2110
0x3000 3.0 - there are two chips listed (in the PS2Ident database) for both revisions 3.0 and 3.1, so maybe this register can show exactly which is the chip.
0x3100 3.1
0x3101
0x4000
0x4110
0x4212 4.2 There are three chips listed (in the PS2Ident database) for rev. 4.2, so maybe they correspond to 0x4000, 0x4110 and 0x4212.
0x4322 4.3
In the EE Core Manual, in the description of PRId, it is specified:
"Note that there is no guarantee that the change in the chip will be reflected in the PRId register, or that changes to the revision number will indicate chip changes. ..."
So it may be that this register - F520 was made just so that software would have a reliable way to identify the EE revision to the exact chip number used.
F520.7:0 might be RDRAM controller revision, or another (even) minor EE revision number - maybe like the A/B/... letters they place after the actual chip number
So it might be worth it adding a functionality to save those registers to the PS2Ident database too and determine the exact chip number from them. (I do wonder if other chips also have little-known identification registers...)
It is not very good cause before dumping user didnt know if he has really Unknown Model or its just a bug.
