FMCB 1.6: Some Questions

[nexXxus86]

Today i installed FMCB 1.6 on my PAL V15 PS2 (scph77004) with Multiboot, because i want to use the same memory card also with my Second PAL PS2 (V7, SCPH39004)

so my first problem is that FMCB uses NTSC, (the logo is NTSC and screwed up on my TV Card)
the Configurator is also NTSC, this sucks because i always have to switch to PAL/NTSC manually in Dscaler.

On the V7 it use PAL, but on the V15 not. Why?

second problem is that it always goes into the PS2 Browser when i turn on the PS2,
i want that it goes directly to the OSD, is that possible?

i set skip sony logo = off in the cfg, but it doesn't work.

any suggestions`?

[TnA]

Originally Posted by nexXxus86

Today i installed FMCB 1.6 on my PAL V15 PS2 (scph77004) with Multiboot, because i want to use the same memory card also with my Second PAL PS2 (V7, SCPH39004)

I have 2 PAL-PS2s SCPH-39004.
You did the right install,...

so my first problem is that FMCB uses NTSC, (the logo is NTSC and screwed up on my TV Card)

For me it shows in PAL and isn't screwed up.
Thought, it gets the PS2-Region + Video-Mode from your Console, so maybe there is an issue with that,...

the Configurator is also NTSC, this sucks because i always have to switch to PAL/NTSC manually in Dscaler.

On the V7 it use PAL, but on the V15 not. Why?

So, it shows both (configurator and Logo) in PAL on your V7?
Both shows in PAL on my V7s.

second problem is that it always goes into the PS2 Browser when i turn on the PS2,
i want that it goes directly to the OSD, is that possible?

i set skip sony logo = off in the cfg, but it doesn't work.

any suggestions`?

Probably you turned on "Go to Browser", which leads you to the "Device-Browser" (where MCs and Discs are shown + HD with Browser 2.0-Upgrade).
Turn off "go to browser".
"Skip-Sony-Logo" is to directly jump to the "swirling electrons".

[dlanor]

@nexXxus86 & TnA:
The problem with the FMCB configurator using NTSC on a PAL v15 is quite real, as I have this myself, and have reported this error earlier.

The reason for this error is that the method used to detect the correct TV mode doesn't work on the v15 PStwo model (and probably some other 'slims'), though it works fine on all fat PS2 models. The same problem also affects uLaunchELF, as that is the program from which the configurator 'borrowed' the TV mode detection code.

The FMCB splash screen had not yet been implemented when I made those earlier tests, and as I installed a proper RGB cable for the v15 (which hides the problem), I forgot about testing this for FMCB itself. But testing it now (again using composite cable) I can confirm what nexXxus86 reported. The splash screen of FMCB does use NTSC on my PAL v15 too, resulting in a monochrome splash image when using composite cable.

Apparently the video init routines for the splash screen use the same faulty routine for TV mode detection as does the configurator and uLE.

So now we have a threefold reason to develop a better method for identifying the console region (at least TV-mode-wise).

Best regards: dlanor

[jimmikaelkael]

I use the same "light" method GSKit uses to detect it :

int gs_detect_signal(void)
{
	if (*(volatile char *)(0x1FC7FF52) == 'E') {
		/* PAL (SCEE) detected */
		return PAL;
	}
	else {
		/* rest of the world is NTSC */
		return NTSC;
	}
}

I've seen this bug on my cousin's 77004.

[dlanor]

Originally Posted by jimmikaelkael

I use the same "light" method GSKit uses to detect it :

uLE and the configurator use similar methods too, though by calling the gsKit function for it instead of doing it directly like your code does.

In uLE this is done by the following code:

	if(gsKit_detect_signal()==GS_MODE_PAL)             //Let console decide
		TV_mode = TV_mode_PAL;
	else
		TV_mode = TV_mode_NTSC;

And here gsKit_detect_signal is the lib function doing almost exactly what your code does.
(The only difference is in the names of the constants.)

I've seen this bug on my cousin's 77004.

Yes, it is indisputably real, and thus we need to fix it (in all three programs).

The problem is obviously that the assumption made by gsKit about the address 0x1FC7FF52 containing 'E' for all european consoles is no longer true for the slim models.

Personally I'm not sure what that address really is (ROM ?), but it is evident that it is no longer used in exactly the same way for a slim PStwo as it was used for the fat PS2 models. So we must find some other way of testing this, which really is common to all models...

Best regards: dlanor

[ffgriever]

@dlanor
Hmm... Either there are different bioses in some V15 or mine is some special case. I bought V15 recently, and it switches to PAL with FMCB (same for other applications with auto settings, including ESR splash).

The string is either moved or not present in your rom. Could you share the dump with me? Just the basic rom, nothing else needed in this case.

@jimmikaelkael
To make it more exact, you can always use romver, but the easy approach will require use of fio (but since you're using it anyway, I don't think it will be that bad ). If you don't want to use fio... just find the beginning of "rom0" image (first RESET) and find ROMVER there. The "filesytem" is exactly the same as in IOP replacement images (I should say it's vice-versa).

So, just start at 0x1FC00000 and compare values directly, it's always 16 aligned and the name is at most 10 chars, including terminating zero, zero padded in all biosses, so just search in memory for whole 64bit 0x0000005445534552 at steps of 16 bytes. After name, the u16 is size in extinfo file, next u32 is file size.


Simple implementation could look like this (since on any console version correct romfs will be somewhere in first 16kB, it will be quite fast:

typedef struct _romfs
{
	char filename[10];
	u16 extinfosize;
	u32 filesize;
} romfs;

int getModeFromRomver()
{
  romfs *romzero = NULL;
  u32 memaddr;
  u8  *romverFile;
  u32 fileOffset;
  
  fileOffset = 0;
  for (memaddr = 0x1fc00000; memaddr < 0x20000000; memaddr += 16) //usually somewhere in first 16kB
  {
    if (*(u64*)memaddr == 0x0000005445534552) //not really best solution, but it's fine
    {
      romzero = (romfs*)memaddr;
      while(strlen(romzero->filename) > 0)
      {

        if (strncmp(romzero->filename, "ROMVER", 6) == 0)
        {
          romverFile =  (u8*)(fileOffset + 0x1fc00000);
          return (romverFile[4] == 'E' ? GS_MODE_PAL : GS_MODE_NTSC);
        }

        if ((romzero->filesize % 0x10)==0)
          fileOffset += romzero->filesize;
        else
          fileOffset += (romzero->filesize + 0x10) & 0xfffffff0;
          
        romzero++;
      } //in theory it is possible to end without finding, because there may be more than one such structures... only one has ROMVER though
    }
  }
  //something wrong
  //display error or just return default NTSC
  return GS_MODE_NTSC;
}

I have actually tested it on few of my consoles, including my only NTSC one... it worked fine.

[Neme]

I think we should be rather going for size as opposed to speed in the launcher, and i wonder if a fio version would be the smaller one.

Edit: looking in launcher.c, it already does it, just not using it for display mode yet.

if((fdn = open("rom0:ROMVER", O_RDONLY)) > 0)  // Getting region char

[ffgriever]

Indeed, it even uses the same data that's needed for mode selection.

fio solution would be bigger only, if you didn't use it earlier in your code at all. This direct method could also be useful, if you wouldn't like to engage IOP and all the other fio heavy machinery . But maybe there is some other, simpler way... so that simply some other location, valid for all the bios versions could be found (or checking in few locations, first for marker, then for value).

[dlanor]

Originally Posted by ffgriever

@dlanor
Hmm... Either there are different bioses in some V15 or mine is some special case. I bought V15 recently, and it switches to PAL with FMCB (same for other applications with auto settings, including ESR splash).

And if you launch uLE without any CNF file present, does it then correctly set a PAL TV mode ?

For me each of FMCB splash, configurator, and uLE mistakenly use NTSC resolution on my PAL v15 (except that uLE can be told to use PAL via CNF).

I can't really tell if the ESR splash suffers from the same problem or not, since the only indication my TV gives of this is that the picture goes monochrome (when not using RGB cable). And since the ESR splash is monochrome in all cases, I have no way of knowing what TV mode it uses. (It would be easier to tell the difference if my TVs did not support NTSC timing perfectly...)

The string is either moved or not present in your rom.

That's the weirdest thing of all. I just inspected a rom0 dump from this v15, and the string IS present, with an 'E' at offset 0x0007FF52.

So from the appearances the gsKit mode test should have succeeded, as the ROM does have the same content in the tested byte as an old fat PS2 would have. And yet the fact remains that this test fails every single time, and the identical test made independently of gsKit in the FMCB splash code also fails the same way.

Could you share the dump with me? Just the basic rom, nothing else needed in this case.

Given the dump I just made, as described above, I think there wouldn't be much point. The rom does have the same byte value in that position as with earlier models, so there must be something else preventing the gsKit test from succeeding. The only thing I can think of right now that could have this effect is if the memory mapping is somehow preventing the gsKit routine from accessing the rom correctly.

If so it is also possible that the method you described, of having the program 'manually' scan through the rom content, could also fail for the same reason as the gsKit test did, because it somehow is unable to access the real rom contents.

But doing it through the normal filesystem, opening the "rom0:ROMVER" file and checking its fifth byte, should work on any console (I think), assuming that this standard has been applied to the oldest models as well, which I'm not really sure of.

Best regards: dlanor

[jimmikaelkael]

Ok I see that's it's tested and works in uLE 4.26
I tested to use the fifth character of ROMVER file and It works for me but not tested on the concerned Slim 7700x...
However I don't see why it will not work, now that dlanor have checked that SCPH 10000 also contain it.

[dlanor]

I've just released a new uLE version (v4.26) which reads the rom0:ROMVER file instead of using the gsKit_detect_signal function, and that has cured the problem of PAL detection on my own v15 as well as the v14 of one user who already reported his results with the new release.

This method really should work on all models, as I've seen that the same file exists even in a rom dump of an SCPH-10000 bios. So I suggest it should be implemented ASAP both for the FMCB splash screen and for the configurator.

Edit:
Ooops! Another post collision.
Anyway, I'm glad you agree on this way to solve the problem.
If you've made the new version available for download, I'll test it for you ASAP on my 77004 v15.

Best regards: dlanor

[jimmikaelkael]

I only implemented it in my current FMCB beta test.
But I hope It will be out very soon

[kevstah2004]

Not a major question but I've wondered why does the FMCB logo texture look more pixelated just before loading a program compared to the one when you install it?

[dlanor]

Originally Posted by kevstah2004

Not a major question but I've wondered why does the FMCB logo texture look more pixelated just before loading a program compared to the one when you install it?

I'm not sure for this particular case, but one common reason for such differencies is when different resolutions are used to display/store a picture.

The installer is a separate program, intended for use once only, and even that time from some media 'roomier' than an MC, so it can afford to waste some space on a more detailed image than the one embedded in the FMCB boot elf on MC.

Best regards: dlanor

[TnA]

Originally Posted by dlanor

I'm not sure for this particular case, but one common reason for such differencies is when different resolutions are used to display/store a picture.

That also might be a case,...

The installer is a separate program, intended for use once only, and even that time from some media 'roomier' than an MC, so it can afford to waste some space on a more detailed image than the one embedded in the FMCB boot elf on MC.

That is one case,...

I thought, the packed BMP is only a half KB, but not sure about,...

[JNABK]

Originally Posted by TnA

I thought, the packed BMP is only a half KB, but not sure about,...

Its actually 4kb....

[TnA]

Originally Posted by JNABK

Its actually 4kb....

...thought it was 4kb with all code.

[jimmikaelkael]

Originally Posted by TnA

...thought it was 4kb with all code.

Maybe it takes more space since I use a more detailed one for interlaced mode...