Ошибка system cnf файл не читается или поврежден

Reading SYSTEM.CNF
Missing TCB
Missing EVENT
Missing STACK
Missing BOOT
TCB = 00000004
EVENT = 00000010
STACK = 801FFF00
BOOT = cdrom:PSX.EXE;1
Configuring kernel
Loading executable
Loading failed
Swap CD now

BOOT = cdrom:SCES_008.66;1
TCB = 4
EVENT = 16
STACK = 0X801FFF00

Fixed already on master. v1.2.2 will support it.

Wow, that was quick, thanks 😀

Wished I’d known that before burning my 10th CD though 😆

Still having the same issue with the d105454 build

Alright. Could you please attach here the SYSTEM.CNF file?

Is that the file from the CD or you copied and pasted the contents into a text editor and uploaded it here? If there are any strange characters that won’t do, and I don’t see anything out of the ordinary from any other SYSTEM.CNF files that could cause the parsing to fail.

As I expected I cannot replicate it. It’s working fine for me.

I’ve modified Tonyhax to display the raw data read from system.cnf and it is just showing a blank line. I have also tried making Kurushi’s config the default values, and Tonyhax attempts to run it, though it gets stuck at the message «Won’t fit. Using BIOS.»

I’ve tried burning another copy and this is still not working. Other games seem to work, so I’m assuming it’s an oddity with the BIOS on the original Fat PS2 (BIOS 09/02/00), the drive, or the crappy CMC Magnetics discs masquerading a Verbatim brand I’m using.

I can’t see anything in the code that should be a miss, so I’ll assume it’s one of the above. Thanks for looking into it though.

I was thinking it could be the PS1-only initialization I am doing at the beginning.

This code is really from when the first reports of PS2s being compatible emerged and I wasn’t truly sure if they weren’t playing some convoluted prank, as the documentation I used to make this said it wasn’t possible. Since the PS2 doesn’t have a fixed address for this information like the PS1 does, I resorted to run it only on PS1, in case the PS2s were really capable not to trash the system’s memory.

There’s a way to fix this on a PS2 which involves scanning around 0x3340~0x3380 on the firmware (the exact offset depends on the PS2 model) for a certain pattern, and that’s why I implemented a memmem function, but I never got around implementing it. Maybe it would be a good moment to try it.

So, after poking around in my PS2’s BIOS, I’ve written the following for the reinit_kernel function:

        if (strncmp(KERNEL_AUTHOR, "CEX-", 4) == 0) {
                // Restore part of the kernel memory
                memcpy((uint8_t *) 0xA0000500, (const uint8_t *) 0xBFC10000, 0x8BF0);

                // Call it to restore everything that it needs to
                ((void (*)(void)) 0xA0000500)();

                // Restore call tables
                memcpy((uint8_t *)      0x200, (const uint8_t *) 0xBFC04300, 0x300);
        } else if (strncmp(KERNEL_AUTHOR, "PS", 2) == 0) {
                // If PS2 Temp work for my particular PS2 - RH
                // Restore part of the kernel memory
                memcpy((uint8_t *) 0xA0000500, (const uint8_t *) 0xBFC03530, 0x8BF0);

                // Call it to restore everything that it needs to
                ((void (*)(void)) 0xA0000500)();

                // Call tables for my particular PS2 - RH
                // Restore call tables
                memcpy((uint8_t *)      0x200, (const uint8_t *) 0xBFC4FC90, 0x300);
        }

This still hasn’t fixed the problem, Kurushi still fails to load, but other games, such as Rayman still work absolutely fine.

One thing I have observed is that when problematic games are trying to load, the drive spines up on the «Loading SYSTEM.CNF» call, then spins down before Tonyhax responds with the «MISSING …» messages. The same thing happens when I hard code Kurushi’s System.cnf details into secondary.c.

I’m now wondering if the PS2 drive requires another command sent to it possibly. I just can’t figure out the difference between the discs that aren’t working versus the ones that are and as to why the PS2 has such difficulty loading them.

What is more puzzling is why the FileOpen to SYSTEM.CNF is succeeding, implying the TOC and ISO filesystem could be read, just to fail reading later.

Actually, does ir really fail? I’m checking for == -1 to be returned from FileRead if it fails, but that’s not triggering

Ok, I’ve added a few debug lines and I can see FileOpen is returning 2, and the length of the data buffer is 70 characters (46 hex), though the data buffer appears blank.

This makes no sense. Either FileRead is not writing to memory, or we are somehow destroying the contents of the buffer. I can’t see anything in the code that could case any of the two to happen.

If I’d hazard a guess it could be a memory alignment issue, the PS2 tends to be very picky about memory. I’ve been writing some PS2 code recently and came across an issue where requesting information about memory cards would silently fail if I didn’t declare the variable as static and __attribute__((__aligned__(64))) so try doing that.

I’m not sure about that. Right now I am using a 2048-byte aligned buffer (see data_buffer in secondary.c)

Could it be clobbering the pointer itself somehow? Might be worth having it spit out the address it’s pointing to right before the read

Sounds highly unlikely — the pointer is marked a «const» so it gets inlined and hardcoded in the assembly. Unless the code is getting corrupted (and there’s the integrity check to ensure it’s not, at least during boot, it could happen that the code gets somehow corrupted later), that shouldn’t happen.

tonyhax-7103e0c7.zip
Could you please try with this file? Note the SPL is now larger so you’d need to update both the first stage and the SPL.

The major difference is that it now explicitely resets the disc drive before initializing it. I was thinking maybe the drive was left in a state where the data was being read, but the controller replied with zeros instead of the actual data, so you got the right length but invalid data.

Same error unfortunately. Kurushi fails to load, but my copy of Rayman is still working. So no regressions.

One thing this build has fixed though is after a failed load, it is able to boot a different game. It was hanging on Initialising CD in previous builds. So I think resetting the drive is still a useful change.

Cddvd registers mapping are different in ps2 mode and ps1 mode. Probably you can’t view the register that store the speed setting in ps2 mode in ps1 mode. (I don’t know).

Maybe you can try create a title.db with the disc code of Tony hawk’s, but with settings for the other game. I have try if I can launch the orca code first and latter ps1drv. But the cd psx controller registers don’t accept any command in ps2 mode. First is needed switch cddvd controller to ps1 mode.(I don’t know how ps1drv made it).

Again sry for engrish, but anyway.
I think I found the cause of this problem. All games with system.cnf issue (RE2/3, Megaman X4, BoF4, Kurushi, maybe Pitfall 3D and Quake 2) have the same feature: SYSTEM.CNF and EXE burned in last sectors image (Pic. 1). I rebuilt Kurushi image, where I changed system.cnf and exe sectors, burned on disc and test on my PS2 (SCPH-39008). System.cnf loaded just fine and game starts.
Now mismatching.
1)I have license copy RE3 and this version freeze on «This game contains scenes» with tonyhax, BUT patched backup copy doesn’t start due to not being able to load system.cnf.
2) Pitfall 3D. I have «Alt. license» version from 90’s (Pic. 2, there’s no image change, only translated title) and this disc load system.cnf just fine. Backup copy — system.cnf not found.
I will try rebuild Megaman X4 for rechecking my theory. If there’s something new, then I will write.
(And, again, sry for engrish, I try write myself and I don’t use GTranslation :/)

Why not try reset the iop?.

I mean in ps1 mode. The emotion engine Was running the gpu emu always. At some time it reset the iop.Then after reboot it enter in ps1 mode. So maybe you can reset the iop and let ps2 reinitialize the cd controller. As the psx was a bios stripped version. It try load the cd and with lucky they don’t made checks. Because was done in osdysys in ps2 mode. Just try jump to 0xBFC00000

Actually the problem with loading backups with SYSTEM.CNF and EXE burned in the last sectors of image also exists with modchipped V7/V8 (at least). Before tonyhax, I was thinking, that it’s a problem of modchip, but tonyhax also shows the same problem.

I been having the same issue as @roberthawdon with Megaman X4 it just won’t boot no matter what. I’ve burned like 4 cd’s with different speeds. Using a ps2 30001.

tonyhax-v1.3.5b.zip

This version does a much more thorough reinitialization of the memory on the PS2. Could you please try it and report back?

@socram8888 Thanks. Imma try it right now. i’ll let ya know!

EDIT : Still not working, gets stuck a bit reading the system.cnf then says Reinitializing kernel swap cd now. Thanks tho!
EDIT 2 : Another game that didn’t work for me was Parasite EVE i just tried it and it said Bios won’t fit or w/e and then loaded lol

@Ledoeye yeah that message means the game’s code overlaps with tonyhax, so instead having tonyhax load it, it uses a bugged system call as a fallback.

I just get stuck on the green screen now.

What code was changed? I can’t seem to find the branch this build is based on.

@roberthawdon v1.3.5 is built from the master branch from commit 5bbb09c. Which console model do you have? Which entry point are you using?

It was the beta that was having issues. Just seen the stable 1.3.5 release. Same issue as before sadly:

Forgot to say, my PS2 is the SCPH-30003 model

Which version of uLaunchELF are you using? I’ve heard multiple reports of version 4.43 corrupting save files, so that would explain why it failed on v1.3.5b while 1.3.5 works just fine.

In fact, between those two version the only change I made was renaming the version (5bbb09c)

I just tried the stable version 1.35 and no matter what MMX4 doesn’t run it gets stuck in the same screen as @roberthawdon.

Alright, thanks for the report. I’m gonna see if I can get my hands on the PS1DRV-mode BIOS of that model and see what’s different about it.

EDIT: Sorry thought you were referring to the solid green screen. The issue with loading SYSTEM.CNF isn’t solved yet and I am not sure if it can even be.

Thanks a lot for your work. Would it work if i got a ps1 instead of ps2?

I can get a ps1 for cheap, which model would you recommend? Any?

Can’t recommend any particular model since I am not savvy enough on the hardware revisions. For what I’ve read the first models had a shitty mechanism made out of plastic that broke, so I’d recommend getting the newest you can.

Okay man, thanks a lot! I’ll just get a ps1 instead, ps2 is not that reliable to play ps1 games sadly. Not to mention i have to use 2 cd’s instead of one because the laser on my ps2 doesn’t read it if it doesn’t have some kind of weight on top of the disc i’m trying to play.

¿Do you have Try another loader? ¿And view if it happend? .

I mean load a cheat code disc with orca, and then launch the kurushi. And view if it boot.

This solved game not loading with old unirom versions.8

Edit:I have successfully boot kurushi the psx mode only have two speed settings.(time ago I have look at ps1 drv).

So i have go to the menu console triangle->playstation driver and set cd-rom mode to faster..

Ant thats all, kurushi boot using my crash bandicot 3.(scph-30004 V3)

I know the hardware register direction where the ps1drv write that valor in ps2 mode… But I really not know if is aviable in ps1 mode. Is in the pcsx2 source code.

It sound as a mechacon bug, that he fail read de last sectors at psx 2x speed legacy mode. As said in the upper post.

If I remember correctly. Ps1drv write 0 If normal psx speed is setting and 2 if faster speed is set in the register. Above of that not matter what number for he all=2 setting.

Only two modes 0,1 2x psx legacy mode >=2 ps2 cd rom mode 24x speed.

Anyway ps1drv first write it in ps2 mode and later reset the iop in to ps1 mode..

So if that register is aviable in ps1 mode or is add as another i/o direction or as a new mechacon command o don’t its aviable in ps1 mode is a totally mistery.

@tic13 could you please tell me that said address? I guess it’d be possible to compile a quick and dirty test version of tonyhax that writes to that register as a test.

New version of loader didn’t help for me. Still games like resident evil fail to read cnf. Final fantasy ix finds the cnf with game exe name, but still fails to read.

Was 0x1F402014 thats where ps1drv write.

in ps2 mode cd rom registers go from 0x1F40200-01F40201F.

Sylph4 Try put playstation driver in to faster setting.

If the ps1drv found in the title.db a speed>2. It write it in the register instead the setting in osdysys(0 for example). So really kurushi entry force it to faster speed.(he have a 9). No matter You set normal in driver settings. But really mechacon interpret it as you put faster speed =2.

If the game we use to boot not have entry or it have 2 or less in speed setting, it take the parameter from osdysys ps1drv setting. I think is how they work.

So it’s better don’t use a game that force faster speed to boot. Then you can set it manually in the ps2 menu as you need.

Another thing I think you can test it’s to change the psx speed between 1x and 2x. As this command is documented in nocash, maybe he can affect it or not. But more options to test.

Edit: I now testing more. I played kuroshi, and now I’m unable to boot it. No matter setting.

Finally it boot sometimes and other don’t load the system cnf. But except 1 time. 99,9% when it load load with faster settting activate.

Is as he don’t like the cd-rom media or so. Totally strange.Sometimes he stuck in initializing CD. As he don’t like media. I need try another disc philips are very bad.

The problem to PS2 System.cnf at the last sector of the disc is solved:

1. The problem is not due to the mastering of the disc. PS2 is capable of booting exe or reading system.cnf at the last sectors of the disc.
2. This problem happens to CDR only. The PS2 drive might spin up and the booting is hang at the PS1 logo screen.
3. The problem can be solved by burning the disc image to a 650MB / 74 mins good quality disc.
4. The problem is probably a PS2 drive design flaw. The same disc can run on a regular PS1 but not PS2. Strangly, the cheap CDR works fine on the PS2 if the exe and system.cnf is not at the end of the disc.

The problem to PS2 System.cnf at the last sector of the disc is solved:

1. The problem is not due to the mastering of the disc. PS2 is capable of booting exe or reading system.cnf at the last sectors of the disc.

2. This problem happens to CDR only. The PS2 drive might spin up and the booting is hang at the PS1 logo screen.

3. The problem can be solved by burning the disc image to a 650MB / 74 mins good quality disc.

4. The problem is probably a PS2 drive design flaw. The same disc can run on a regular PS1 but not PS2. Strangly, the cheap CDR works fine on the PS2 if the exe and system.cnf is not at the end of the disc.

Old Sony docs actually said that anything over 72 minutes is not officially supported for burned CD-R media but that was involving the original psx. The original psx has a seek table optimized for 72 minute media I belive, and it was even recommended that the last 3 minutes contains a dummy track so that the drive isn’t seeking in that area. Maybe it is more problematic on the PS2, because i.e. this is how tocperfect patching works (puts the tonyhax executable at the end of the disc).

btw, sry for eng
Now I have a second PS2, SCPH-30001R with modbo 760, it has a same problem with cnf and exe at end of disc:
1)With tonyhax — system.cnf not readable, exe not found
2)Without tonyhax — freezes on PS1 logo
But If I try open system.cnf on disc via text editor in ULaunchELF — it actually opens and shows me all text in the configuration file. However with modchip PS2 thinks it’s PS2 CD game (that’s what ULE show me). That’s how «modern» modchip works.
I don’t think this is a CD-R problem, maybe it’s really a mechacon bug in PS1 mode?