Formula One 2000 Issue

[gyyo93]

Hello, I have a question, why NO$PSX cannot continue working in Formula one 2000 after the first cutscene, i.e. the first loading. Refers to SLUS_011.34 and SCES_027.77. While epsxe2.0.5 and duckstation support? Any reply and help would be greatly appreciated.

[MasterLink]

Can confirm, after the loading screen it goes black. Even tried putting in a BIOS in the root directory of where the emulator is named PSX-BIOS.ROM per the manual in case, but no change.

TTY Debug Window:

Screenshot 2025-02-20 165230.png

Something to note, while DuckStation does run it, notice it says it's applying a "Compatibility" setting for this specific game, "CPU Recompiler Disabled", indicating this game does need special care.

[MasterLink]

So, while I don't think nocash has seen this post, or perhaps doesn't know what's going on, I *think* I have two hypothesis based on what I observe in No$PSX. It appears to get caught in an infinite loop.

Perhaps this game has self-modifying code (SMC)? I *have* seen some emulators CPU cores have issues with SMC's, and get caught in loops kind of like this.

Just a huge theory though, as I did run into another emulator with the same issue as No$PSX, but ironically it's a 20 year old emulator with no debugging, but it does use an Interpreter rather than a Recompiler.

(I honestly assumed No$PSX uses a Recompiler though, as an Interpreter would be slower? So this theory may be just flat out wrong.)

EDIT: Actually, this game seems to load multiple executables in RAM based on the TTY output. It appears to be pulling up a different executable. SBIOS's System File Loader going wrong?

[gwald]

I think the CDROM support on no$psx isn't 100% yet, but I don't know.
I think there shouldn't be any "not found" in that TTY log.

[MasterLink]

I think the CDROM support on no$psx isn't 100% yet, but I don't know.
I think there shouldn't be any "not found" in that TTY log.

I noticed that, but here's the kicker, the not found errors, those files really aren't actually on the disc, but the games code is indeed looking for them. I can only speculate that perhaps they compiled one executable for multiple regions, but that does sound rather silly and unoptimized to do.

Perhaps it is what's causing it though, just not sure. I *should* try forcing DuckStation to use an Interpreter and other emulation cores to see if the bug does creep up, but thus far I can't get DuckStation to stop overriding this behavior where it goes in compatibility mode with some games such as this.

[Administrator]

I think the CDROM support on no$psx isn't 100% yet, but I don't know.
I think there shouldn't be any "not found" in that TTY log.

Please be more careful with your posts as that is such an unintelligent statement. "I think the CDROM works but I don't know". Why even say that if you don't know. How is that a helpful reply to everyone. Why not run some tests on other emulators and give some constructive input.

You do realise that the NO$PSX emulator is one of the most accurate emulators available, and a lot of other emulators use NO$CASH's documentation to build theirs up. The NO$PSX emulator is also the only emulator that emulates the HC05 core correctly by physically utilising the Motorola assembly logic found in the actual PlayStation console. It's literally running the exact same memory dump from a retail unit.

The "Not Found" is most likely the CdSearch command returning the file results. The developers seem to have forgotten to omit some of the entries or it could also be skipping the language files after a selection is made. Either way, it is a bit silly because those are largely wasted seek times if it's actually trying to find them.

[gwald]

Why all the "I think" you ask?, well because around mid 2010's, I remember having issues with Net Yaroze code playing CDDA audio on no$psx, and I tried mednafen and it just worked. And it stuck with me but I tested it now and my NY CDDA also worked. So