BIOS region check routine bypassing

[wisi]

The file attached in this thread describes the SSBUSC configuration registers. Some features are missing in PS1 mode (which should be the same as on the PS1).
https://assemblergames.com/threads/the- ... ost-960878

The PS2 has a functioning /WAIT signal but not all devices have it enabled (and I think some didn't support it at all), so even if the PS1 had one, it would have probably not been enabled for the BOOT ROM.
I have tried patching the PS2 BOOT ROM with an overclocked (to ~ 20MHz*4) PIC MCU, but the number of instructions necessary to modify the data (~10 per BOOT ROM read cycle) were too many, so it was still too slow to work. At the end, for the test I was doing, I ended-up using a (72 macrocell) CPLD.

BTW, RAM I/O is configured through another register - 0x1F801060.

One way to use a slower MCU (although it would still need to be pretty fast) for patching the ROM, would be to use the PS1 CPU clock for the MCU and use this synchronization to remove the need for synchronization instructions in software (i.e. once the code detects that it should start patching, you would know exactly for how many cycles it would have to output each byte and when to switch to the next).

[rama3]

So this would be a big project.
We need an MCU that is fast enough and has enough I/O to do the patching.
It may get a little easier once we get a chance to patch the correct access time configuration register.
We could tell it to go as slow as possible, freeing up cycles on the MCU.
The idea to clock the MCU using the CPU clock is good. I don't think those ~33Mhz would be fast enough for the MCU, so the MCU would have to have clock multiplying of some sort.

Anyway, it'd be a cool project but I don't have the time for all that right now

Off topic:
Yo wisi!
Could I interest you in taking another look at PCSX2's PGIF?
Would be awesome

[wisi]

It becomes problematic around branches, as you don't know what will be the next byte the CPU will load from ROM. I noticed some rather odd behavior regarding the order in which the IOP would load the data. Still it may be a bit easier on the PS1.
I think that on boot-up the ROM is configured to really low speed - only later the timing register is reconfigured, so it may be only a matter of noping-out that instruction.
Off topic:
Check the other communication channel.

[rama3]

Good to know, I'll remember this and check, if I ever get to it

It also sounds like my wish-MCU for the job (ESP32) might be able to deliver conditional data quickly enough.
The I/O toggle limit is at least 40Mhz in software(!). I recently built an entire SNES clock generator (21.477Mhz default, but variable from 15 to 35Mhz tested and working) with 10 lines of Arduino sample code. It is that simple these days ;p

If things go wrong, it has JTAG to debug the issue.
So yeah, I'd really like to try this chip for the task.

[Myria]

For whatever reason, American PS1s never checked the license area. Even American PS2s don't--for both the PS1 and PS2 license/logo areas. (On DECKARD PS2s, it appears that the DECKARD has functionality to hack the region byte of the PS1 ROM, and the disk loader obeys this...? DECKARD PS2s have the same BIOS in all regions.)

The only theory I have as to why the American PS1s and PS2s don't check the license area is the Sega v. Accolade court case.

My SCPH-7000W has an American BIOS: its memory card and CD player are in English instead of Japanese, and it runs all regions' games, so it kind of had to be I guess.