Best way to detect SH3 or SH4 cpu?

[Ziqumu Profile]

Hello,
I'm the author of the SH4 Compatibility Tool and in order to fix some compatibility problems, I need to have the cpu type : SH4 (Power graphic 2) or SH3.
Until now I was using the OS version number : is SH3 if version<=2.01 else SH4. But since some days we have a new OS update and both are 2.04.
I could still get the cpu by knowing each version and build number, but this mean I need to update the SH4 Compatibility Tool every new OS update. And at each update all addin will need to be put in the SH4 Compatibility Tool again to be compatible with new OS version.

So I would like to know if someone has a better idea, or know something that give us the hardware type (and a fast way as it will be in the keydown function) ?

[SimonLothar]

This is, what I use:

Detecting the MPU type of fx-calculators
The SH-7305 has the processor version register (PVR) 0xFF000030 and the the product version register (PRR) 0xFF000044, which are available since the SH-4 microprocessors. These can be used to positively detect a SH-7305. With SH-7337 and SH-7355 the registers yield some unpredictable results. Though, the MPUs do not enter any exception state.
BTW: the CPU core ID register CPIDR H'FF00 0048 returns 1 on the SH-7305.

With SH-7337 and SH-7355 the Port L control register PLCR H'A400 0114 can be used to distinguish between SH-7337 and SH-7355. With SH-7337 bits 8..15 of PLCR cannot be set. This is in accordance with the SH-7705 manual. With SH-7355 bits 8..11 of PLCR can be set. Mind to save and restore PLCR. The register controls the analogue input of the ADC, which is used to check the battery voltage.
Though H'A400 0114 is not a documented register address on the SH-7305, it yields zero and does not trigger any exception.

The following scheme could come in handy:

Save the contents of PLCR: savevalue = *(unsigned int*)A400 0114
Write 0xFFFF to PLCR: *(unsigned int*)A400 0114 = 0xFFFF
Read the modified PLCR: testvalue = *(unsigned int*)A400 0114
Restore to original value: *(unsigned int*)A400 0114 = savevalue
Process testvalue:

Code: Select all

savevalue = *(unsigned int*)A400 0114
*(unsigned int*)A400 0114 = 0xFFFF
testvalue = *(unsigned int*)A400 0114
*(unsigned int*)A400 0114 = savevalue
MPU = UNKNOWN;
switch ( testvalue ){
    case 0x00FF :
        MPU = SH7337;
        break;

    case 0x0FFF :
        MPU = SH7355;
        break;

    default :
        switch ( *(unsigned int*)0xFF000030 & 0xFFFFFF00 ){
            case 0x10300B00 :
                switch ( *(unsigned int*)0xFF000044 & 0xFFFFFFF0 ){
                    case 0x00002C00 :
                        MPU = SH7305;
                        break;
                   
                    case 0x00002200 :    // just for reference
                        MPU = SH7724;
                        break;
                };
                break;
        }
        break;
}


Call the function at program initialization and store the result in some global variable. Use this variable in the course of your program. This would be fast.

[Ziqumu Profile]

Thank you !

Can you confirm me that :
- SH7305 is Fx9860GII SH4
- SH7337 is Fx9860G SH3
- SH7355 is Fx9860GII SH3

Call the function at program initialization and store the result in some global variable. Use this variable in the course of your program. This would be fast.

If I make my own program, yes, that's why I will do, but SH4 Compatibility Tool replace binary code by another binary code so it's not so easy. Maybe I can do something like putting a free byte in the asm code that will be edited by the code. But i don't know if the calc alway allow to write directly where the addin is executed.

[SimonLothar]

Can you confirm me that :
- SH7305 is Fx9860GII SH4
- SH7337 is Fx9860G SH3
- SH7355 is Fx9860GII SH3

Yes.

[SimonLothar]

If I make my own program, yes, that's why I will do, but SH4 Compatibility Tool replace binary code by another binary code so it's not so easy. Maybe I can do something like putting a free byte in the asm code that will be edited by the code. But i don't know if the calc alway allow to write directly where the addin is executed.

The addin itself is located in the flash mapped to a virtual address space. That area cannot be written to. All fx-9860-calcs have 256k RAM in common, physically starting at 0x88000000. You have to find a byte, which none of the OSes uses. Perhaps there is an unused writable MPU-register, which the three MPUs have in common.

[haflab Profile]

Can you confirm me that :
- SH7305 is Fx9860GII SH4
- SH7337 is Fx9860G SH3
- SH7355 is Fx9860GII SH3

Yes.

I have a new graph 35+usb that I tweaked to graph75. The displayed version was 02.04.2201.
(it is now 02.02).
fxremote says that the processor is SH735501.
I guess that the processor is anyway SH4, as SH3 tools often reboot the calculator, and that a SH4 clock designed for SH4 processor works well.
It that possible that fxremote is not accurate? (for example falls in a "else" in a "case" loop) ?

[SimonLothar]

It is a matter of protocol 7.00, function GetDeviceInfo. The function returns RENESAS SH733701 in the processor identifier field for the G-types and RENESAS SH735501 for the GII-types. They did not bother to change the processor identifier for the GII-2-types. GetDeviceInfo of these calculators still returns RENESAS SH735501 in the processor identifier field. The MPU of the GII-2-types is the SH7305.

[SimonLothar]

I couldn't find a precise documentation of the PVR/PRR registers, where did you find it?

PVR and PRR are documented in the SH7780(4A)-manual rev. 1.00 p. 1276 and SH7760(4)-manual rev. 2.00 p. 1329

[cakeisalie5 Profile Website]

Oh, so that's a SH-4A thing! I now understand why you don't use it to identify MCUs using SH3

[SimonLothar]

Hi, I was discussing ... the last four digits of the version, and ... they were automatically made up from detections on the hardware (as the same OS on different hardware gives different digits).
So I was wondering if you knew how the OS knew all that info, so if there is a way to know:
- if the model is a french/other one (Graph, ...);
- the board ID.

The following results are based on calculators and OSes I own.
Possibly things vary with calculators purchased in different countries.

The OS version is generated in the following manner:
syscall 0x015: int GlibGetOSVersionInfo(char *a, char *b, short int *c, short int *d);
---
a and b are hard coded inside of the OS and represent the main OS version.
---
c is zero with OSes 1.xx and 0x1000 with OS 1.05AU (hard coded inside of the OS).
Since OS version 2.xx c partly depends on the hardware-information inside of the bios (at about 0xA0000300)

The first nibble of c is 1 if *(char*)0xA0000303 == 'E' (giving 0x1???)
The first nibble of c is 2 if *(char*)0xA0000305 == 0x55 (giving 0x2???)
The first nibble of c is 5 if *(char*)0xA0000305 == 0x99 (since OS 2.05; giving 0x5???)
Else the first nibble of c is zero (giving 0x0???).

The second nibble of c is 1 with OS 2.00 designed for the fx-9860G slim (hard coded inside of the OS; giving 0x?1??)
The second nibble of c is 2 with OSes designed for fx-9860GII calculators (hard coded inside of the OS; giving 0x?2??)
The second nibble of c is 3 with OS 2.00 designed for the fx-9860G AU (hard coded inside of the OS; giving 0x?3??)
The second nibble of c is 7 with OSes designed for fx-9750GII calculators (hard coded inside of the OS; giving 0x?7??)
The second nibble of c is 7 with OSes designed for fx-7400GII calculators (hard coded inside of the OS; giving 0x?7??)
Observed in g35 OS 2.09:
The second nibble of c is 2 with OSes designed for fx-9750GII calculators at least since OS 2.09 but not with and not before OS 2.04 (hard coded inside of the OS; giving 0x?2??)

The third nibble of c is zero in every case I investigated.

The forth nibble of c is 0 with SH-3-OSes (of course hard coded inside of the OS; giving 0x???0)
The forth nibble of c is 1 with SH-4A-OSes (of course hard coded inside of the OS; giving 0x???1)

---
d is always zero