Japanese support by Mottzilla and Alex

[alex-free]

In this pull request:

• Japanese console support via SetSession or our SetSessionSuperUltraCommandSmash bypass method of updating the TOC.
• Add displaying CDROM Controller BIOS version in loader.
• Changed .mcd file extension to .mcr for FreePSXBoot images (.mcr is recognized by Memory Card Annihilator but .mcd is not).
• Add submodules for mkpsxiso and crosstool-ng (crosstool-ng is how the mips-linux-gnu-gcc toolchain debian package is made).
• Add scripts that can install a self-contained local mips-linux-gnu-gcc toolchain on any Linux/BSD/other OS supported by crosstool-ng. No longer do you need WSL or real debian and the mips-linux-gnu-gcc distro-specific package.
• Add script that burns boot CD for testing.
• Add script that builds tonyhax sources with local toolchain.
• Changed mips-linux-gnu-gcc-10 to more correct and generic mips-linux-gnu-gcc (make sure if you use WSL you install mips-linux-gnu-gcc NOT mips-linux-gnu-gcc-10 as that does not provide a generically named mips-linux-gnu-gcc compiler).
• Add TOCPerfect and DemoSwap functionallity to loader (see https://alex-free.github.io/ps1demoswap, I think it would be quite interesting for you to read).

Known issue: Japanese consoles do not support anti-freepsxboot patches. Memory card in slot 2 must be removed after loader is booted via exploited memory card.

I have a SCPH-1000 VC0 B and SCPH-7500 VC3 A which I have used for testing.

I know this is a substantial amount of changes for one pull request. Let me know your thoughts.

Note: This source has been extensively tested and in development for months. It is not currently in the PS1 DemoSwap Patcher program but will be in the next update. Currently the latest PS1 DemoSwap Patcher program uses a slightly older version of this source.

Note: Me and Mottzilla are the first to solve the SetSession bug on the early VC 0 A/VC 0 B/ VC 1 A firmwares. We discovered a work around that allows updating the TOC.

[AKuHAK]

Its just my opinion but I think taht it is better to split this pr in several commits, just in case some bugs occured in the future.

[alex-free]

Its just my opinion but I think taht it is better to split this pr in several commits, just in case some bugs occured in the future.

If it is required to remove the TOCPERFECT and STEALTH defines I can do that and change the commit for this pull request. I would definitely prefer them to be included in tonyhax but can understand how they could deviate from the original project's goals as they are used by the PS1 DemoSwap Patcher program exclusively.

Everything else however like the toolchain stuff should all be included IMO. It's been tested and it allows me to build tonyhax on Fedora Linux. Not everyone wants to use Debian, mips-linux-gnu-gcc 10, and WSL.

[AKuHAK]

@alex-free I was not talking about removing any of functionality. Just split your single commit into several commits where each one provides one function. It will be easier for maintainers to review your code and will be easier for you to provide requested changes if there will be some. It alao be easier for future bug catchers to locate possible bugs.

[socram8888]

I really cannot accept this PR:

• I don't have any Japanese console to test it
• I'm afraid all the changes might break support for any of the currently supported and tested games, specially considering you're initializing the gamepad structure which is buggy as hell
• My OCD is constantly triggered with how broken the code style is - it's become a mess of K&R, Allman and has missing/excess of spaces everywhere.
• You've included files which should be gitignore'd, like .config

[alex-free]

I really cannot accept this PR:

* I don't have any Japanese console to test it

* I'm afraid all the changes might break support for any of the currently supported and tested games, specially considering you're initializing the gamepad structure which is buggy as hell

* My OCD is constantly triggered with how broken the code style is - it's become a mess of K&R, Allman and has missing/excess of spaces everywhere.

* You've included files which should be gitignore'd, like .config

The .config file is included specifically for crosstool-ng. It is used to build the toolchain. I wrote it to build the toolchain in a self contained sub module without installing it anywhere else. Look into the scripts.

Is it possible to get any of this in tonyhax (like the toolchain stuff to support building on more OSes)? I am open to changing stuff, I can try a different commit with a more consistent style.

You can test this without a Japanese console. Set enable_unlock = 0.

Do you have any ideas on why the anti-freepsxboot patches don't work on Japanese consoles?

[socram8888]

The .config file is included specifically for crosstool-ng. It is used to build the toolchain. I wrote it to build the toolchain in a self contained sub module without installing it anywhere else. Look into the scripts. Fair enough.

Is it possible to get any of this in tonyhax (like the toolchain stuff to support building on more OSes)? I am open to changing stuff, I can try a different commit with a more consistent style. I'll look into allowing cross compilation without depending on Debian.

Do you have any ideas on why the anti-freepsxboot patches don't work on Japanese consoles? They might be using a different BIOS. If the read card sector finite state machine is different then it won't work.

[alex-free]

The .config file is included specifically for crosstool-ng. It is used to build the toolchain. I wrote it to build the toolchain in a self contained sub module without installing it anywhere else. Look into the scripts. Fair enough.

Is it possible to get any of this in tonyhax (like the toolchain stuff to support building on more OSes)? I am open to changing stuff, I can try a different commit with a more consistent style. I'll look into allowing cross compilation without depending on Debian.

Do you have any ideas on why the anti-freepsxboot patches don't work on Japanese consoles? They might be using a different BIOS. If the read card sector finite state machine is different then it won't work.

Japanese consoles are all using different BIOS versions then USA/PAL. What would be the right way to figure out how to make it work on these consoles?

The cross compilation works great with the build-internal-toolchain and build-with-internal-toolchain scripts. The .config file is read by crosstool-ng and creates the toolchain.

If I clean up the code style would you be open to another pull request? Like I said you can test the Japanese support on USA/PAL consoles if you force the enable_unlock = 0.