PCSX2 version:v1.5.0-dev-1025-gcff8cb1 (2016-07-27; ).PCSX2 options:Defaults. No options modifications affect this issue.Plugins used:Defaults (GSdx32-AVX, LilyPad, SPU2-X, cdvdGigaherz, USBnull, FWnull and DEV9ghzdrk). No particular plugins affect this issue.Plugin settings:Defaults. No settings modifications affect the issue.Description:If any game is full booted with pnaches (such as cheats and/or widescreen hacks) enabled, PCSX2 currently attempts to inject them into live memory between the end of the 'Sony Computer Entertainment' animation and prior to the start of the 'PlayStation 2' animation. As a result, game pnaches have the potential of corrupting BIOS memory, triggering freezes, log errors and even crashes.Would it be possible to modify PCSX2's patching engine to only inject game pnaches into live memory after the 'PlayStation 2' logo animation has ended (once the BIOS has been cleared from live memory)?How to replicate:.
Download PCSX2 - Playstation 2 BIOS (PS2 BIOS) Emulator: PCSX2 - Playstation 2 BIOS (PS2 BIOS) User rating. (Just add game and PS2 BIOS, and a snack preferably!). The necessary cheats already integrated as.pnach file (01B2FA7F.pnach). Welcome to emuparadise.org's BIOS section. Over here, we have a great selection of BIOS files for people who are trying to emulate and need a BIOS to get through. The BIOS's come in handy when you need to use one with an emulator, so you can look to this section for all your BIOS needs!!
This has only been tested with my North American launch PS2's dumped BIOS: USA v01.20. Since these replication steps are based on pnach/BIOS memory conflicts, the outcome might not be reproducible in other BIOS revisions if their conflicting addresses differ from mine.
The pnach in step 5 is deliberately extremely long to increase the odds of conflicts. Launch PCSX2 and fast boot any game. In the log window, take note of the game's CRC. Exit PCSX2 completely. In PCSX2's cheats folder, create a pnach named after the game's CRC (example: 2EDE12D1.pnach).
Place 's contents into the pnach. Ensure cheats are enabled by going to 'System - Enable Cheats'. Full boot the game. The BIOS' 'Sony Computer Entertainment' startup animation will play, followed by a frozen black screen. Depending on your BIOS, log errors and crashes may also occur. The 'PlayStation 2' logo animation will never be reached.
Step 9 didn't work as expected. Both the 'Sony Computer Entertainment' and 'PlayStation 2' animations should've been able to playback fully, regardless of what the pnach does.
Freezes/log errors/crashes as a result of the pnach's hacks shouldn't of occurred until after the 'PlayStation 2' animation finished playing.Last known version to work:. Never worked. Oldest tested version: R5766 (2013-12-05; ).PC specifications:CPU: Intel Core i7 2600K @ 3.4GHz; GPU: XFX Radeon HD 6970 2GB; GPU driver: Crimson 16.2.1 Beta; OS: Windows 7 SP1.Other comments:.
This is the 'other' full boot pnach bug I referred to in. There's a risk that whatever gets implemented to fix this might cause 's issue to start occurring in full boot mode (it currently only affects fast boot). FYI. Wow, that's surprising:O. With my BIOS, in, my console log produces 2 consecutive redundant messages about the same cheats being loaded in prior to the start of the 'PlayStation 2' animation. If I use hacks that I know will clash with BIOS memory, the same cheats messages appear at the same point in time, followed by a black screen instead of the 'PlayStation 2' animation.Here's a.PS: The widescreen archive contains optional BIOS pnaches (called 00000000.pnach).
Ideally, anything that gets done to resolve this issue should retain compatibility with those kinds of pnaches. I should've mentioned this in the OP's other comments section, but it didn't cross my mind at the time. The message at the console indicates that the patches were loaded - not that they're being applied, and the patches are reloaded on boot, pause, and on every configuration change (e.g. If you change some option at the menu), but we try not to spam the console with these messages so we only display them once after the CRC has changed, or at least that was the intent.Patch lines which start with patch=1. Are applied (patching the memory) on every PS2 vsync, and lines which start with patch=0.
Are applied only at the very beginning when the game starts.Might be obvious, but for the sake of clarity, only patches which were loaded are getting applied.The widescreen archive contains optional BIOS pnaches (called 00000000.pnach). Also looked at it recently, and he's in the process of breaking stuff, and hopefully he'll be able to put it back together better than it was.Well. Seems it worked out. Please check again, I believe this bug should now be fixed.Even better, with a small followup commit which I just pushed, I think that the patches system is now quite reliable (famous last words).
Game startup detection should be very reliable, patches should get applied exactly on time and not too soon/late, they're cleared on reboot, etc.(or others obviously), I'd appreciate if you could do some patches/cheats testing and let us know if you notice any remaining issues with the patches system, and/or that we didn't break the other recent improvements (, bios patches, others?). Thanks for all your help with this:)! I first ran into this full boot issue over 2 years ago, but never got around to reporting it until now. This and some of the other pnach issues I've reported/participated in had hindered my experience developing widescreen hacks overtime. Please don't open new bugs on these subjects until we can clarify here which are bugs and which are.
I used a hack to overwrite an arbitrary address, dropped it into a 00000000.pnach file and full booted.I don't understand this one fully. What's the 'hack' and why is it a hack? You mean while another game is running, which worked because we didn't reset them on reboot? (doesn't seem so I think, since 00000000 would not been loaded if a game had another crc).
Are you saying that bios patches now never work? Please provide exact steps to reproduce this, as well of more details on how you made it work in the past with the 'hack'.
Also, a please provide real-world use case where what you're trying to do would be useful. Since, two redundant groups of patch-related messages appear directly one-after-another whenever patches are loaded.I can confirm, and I see where it comes from, but will need to think how to handle it properly.
Regardless, this is only an issue with the messages being displayed or not, not with actual loading of the patches. The double console message on boot and missing message when loading a savestate should be fixed with.The bios (0x00000000) patches should now work with (haven't tested it).I don't intend to modify the console messages when changing settings which specifically relate to patches. As I mentioned, you're on your own there. If you want, enable the dev console and see the info you need.I's appreciate if you could confirm the fixes, and let me know if you think there are still patches related issues other than the console message when changing settings.
Here are my responses to your first recent reply for items 1-4 (for things that I'd consider to still be relevant at this point).1)Also, a please provide real-world use case where what you're trying to do would be useful.BIOS widescreen hacks. See for more info.
The forum's widescreen archive currently contains a few 00000000.pnach files for specific BIOS revisions. They're currently omitted from the PCSX2 repo's cheatsws.zip archive.3)Is this a new issue with the recent commits?No.Before the details, please keep in mind that applied patches cannot be 'undone', because.I agree with you on this. My impression has always been that it would be unrealistic to attempt to 'undo' patches via toggling. Looking back at what I wrote, I don't think I was very clear about what I was trying to get at. What I had in mind with 'toggling' was the act of starting up a game without patches, then enabling them while the game is in the middle of running.According to the current (and past) semantics they're only applied on load. When loading save state it doesn't load the game, it loads the state dump from the previous save. 0 patches, if they were applied while you saved the state, already took whatever effect they had on the game, and the saved state should already have them applied.As for enabling cheats while in game, while some argument could be made that the 0 patches should be applied, I still think they should not.I just find it strange that new 1 patches can be introduced into a patchless save state simply by loading it while patches are enabled (or enabling patches after it's been loaded), whereas the same can't be done for 0.
Considering the vague definition of a 0 patch is to 'write once', I'd figure it'd make sense to write once any time a game or save state is loaded, or when enabling patches while a game is running.Do we know for sure that 0 patches not being applied when loading save states or enabling them in mid-game were intentional decisions, as opposed to unintended bugs that had never been brought up until now?4)Yup, I might be able to do something about that, but it's not critical. As I noted with (2), if you're a patch author and need more verbose patches messages, you can enable them.I was just thinking that for general troubleshooting purposes, it may be useful to log the first time a given game's patches are enabled under all circumstances (not just when a game is launched or a save state is loaded).Imagine if a newbie ran into problems related to enabling patches while their game was in the middle of running. If they were to post about it in the forums and provide a log, assuming they held onto default settings (where Dev/verbose isn't enabled), their log wouldn't contain any indication they had ever made any attempt to load patches at any point, which may make it more difficult for other users to help troubleshoot.I personally don't feel strongly about it for my own purposes, so I'll leave it at that.The patches system in general is really not meant to be messed with while a game is running.Agreed. Although for anyone developing patches, if they have a good understanding of what they're doing, it can sometimes be very handy to have the ability to mess with it in mid-game (at least from my own experience).Here are a few more patch issues I recently came across in (probably via ).5)If I enable hacks and use a BIOS patch file (00000000.pnach), any type 1 hacks therein will be continuously written into game memory when full booting.
For example, if I full boot any game, the BIOS' type 1 hacks won't cease being written into memory once the 'PlayStation 2' logo animation finishes. They'll continue to be written into memory after the game has started.6)The same issue as 5) occurs for both type 0 and 1 hacks when fast booting games. The fast boot issue existed in and prior commits. BIOS widescreen hacks. Also, as far as I can tell, we now have only 3 issues which didn't fully conclude:. Whether or not to apply 0 patches when loading state. Whether or not to display messages by default when enabling/disabling patches while the game runs (i.e.
Patches are loaded and applied correctly but only visible at the console when the dev/verbose source is enabled, and you want the messages also by default). Your claim that 1 bios patches are applied to the game continuously together with the game's 1 patches - after the Playstation 2 logo, with either full or fast boot. In other words, that the bios 1 patches are never unloaded.Please confirm that these are indeed the only not-fully-concluded subjects. Are you aware of specific place=0 patches out there which work with normal fast of full boot, but not when loading a saved state which was saved after boot where they were enabled?No. What I had in mind in my previous comments was that if someone wanted to introduce a 0 patch into a patchless save state upon loading it, current behavior wouldn't allow them to.I'm not saying you're wrong, but I'd need a test case to reproduce here. As far as I can tell from the code, this cannot happen. In PCSX2's cheats folder, create a pnach file name named 00000000.pnach and insert the following content into it: patch=1,EE,206E1500,extended,43BA0000 //43F80000 - Test.
Launch PCSX2. Ensure cheats are enabled and widescreen patches are disabled. Launch Cheat Engine (or a similar external memory viewer), open PCSX2's process, add address 206E1500, then right click on it and select 'Show as hexadecimal'.
In PCSX2, full or fast boot any game. In Cheat Engine, observe address 206E1500's value. During BIOS startup animations, it'll be 43BA0000. Once the game starts running, it'll remain as 43BA0000. In Cheat Engine, change address 206E1500's value to 00000000.
PCSX2 won't revert it to 43BA0000. Step 6 didn't work as expected. Once the game started up, 206E1500's value remained as 43BA0000. It should've been whatever the game intended to set that address to. Step 7 shows that patch type 1's 'always write' functionality was longer in effect after the game launched.2. Whether or not to display messages by default when enabling/disabling patches while the game runs (i.e.
Patches are loaded and applied correctly but only visible at the console when the dev/verbose source is enabled, and you want the messages also by default).This can be dropped. I don't care strongly about it. I only identified it because I perceived what was currently being done to potentially be inconsistent behavior.3. Your claim that 1 bios patches are applied to the game continuously together with the game's 1 patches - after the Playstation 2 logo, with either full or fast boot. In other words, that the bios 1 patches are never unloaded.Yes, but this also applies to type 0 patches when both fast and full booting (although games overwrite them upon launching).Please confirm that these are indeed the only not-fully-concluded subjects.Correct, but 2 can be dropped.
3 is the most notable. Correct, but 2 can be dropped. 3 is the most notable.3 indeed is what I wanted to start with too. I'm still fine with discussing 1 and 2 further, but after we're done with 3 and possibly other remaining issues.6 In Cheat Engine, observe address 206E1500's value. During BIOS startup animations, it'll be 43BA0000.
Once the game starts running, it'll remain as 43BA0000.7 In Cheat Engine, change address 206E1500's value to 00000000. PCSX2 won't revert it to 43BA0000.8 Step 6 didn't work as expected. Once the game started up, 206E1500's value remained as 43BA0000. It should've been whatever the game intended to set that address to.
Step 7 shows that patch type 1's 'always write' functionality was longer in effect after the game launched.So, in your list, I'm not quite sure what works and what doesn't work, and what you expect.STR (steps to reproduce, which are preferably also minimal steps to reproduce) is typically in the form of 'Do A, B, C. Calado show. I'm then expecting X, but instead I get Y'. Observations during A/B/C are OK, but the focus is still on the X/Y part and how to get there (A/B/C/.).
This would allow me to try and reproduce (do A, B, C, get Y) but also to make sure that our expectations are aligned (that we both indeed expect X to happen instead).At 5 you say fast or full boot, but in 6 you say 'during the bios animation', which only happens during full boot. So is this STR only for full boot? At 5 you say fast or full boot, but in 6 you say 'during the bios animation', which only happens during full boot.
So is this STR only for full boot? I'm OK with focusing on full boot first if the fast boot STR is meaningfully different, otherwise, I don't see how you can do anything during bios animation in fast boot, because there shouldn't be such animation.I wrote that STR with full boot in mind, so let's go with that.Sorry for the confusion I caused by mentioning fast boot in step 5.
When observing in Cheat Engine, fast booting causes 43BA0000 to be briefly written to address 206E1500 just before the game's ELF is loaded into memory. The game's ELF then overwrites it with its own value. It doesn't cause any problems, but it seems strange that 00000000.pnach would attempt to activate at all when fast booting (since the BIOS isn't in play in that scenario).Or maybe 5 means 'If you did full boot, then you'll be able to observe that the patch works correctly during the bios and the value at 206E1500 is 43BA0000 while the bios boots - as expected'I assume you meant 6 here?
If so, your understanding is correct. It worked fine during the BIOS screens.I'm also not sure whether each of steps 6/7/8 (individually) belong to the A/B/C part, or if they're the X/Y, especially since you describe 6 as a fact (so I assumed A/B/C), but then at 8 you say that 6 doesn't work (which now makes me think it's X).6-7 are observations.
8 is a mix of X and Y.By 'step 6 didn't work as expected', do you mean that during the bios it's not 43BA0000? Or that it doesn't remain 43BA0000 once the game starts?
I don't think I have other interpretations for '6 doesn't work'.It is 43BA0000 during the BIOS startup screens. The problem is that it remains as 43BA0000 once the game starts. The game starting part is what I was trying to emphasize by saying 6 didn't work as expected.Step 6 ends with 'Once the game starts running, it'll remain as 43BA0000'.
Does that mean that you do 7 while the game is running?Yes. The point of step 7 was just to show that even though 43BA0000 has been injected into game memory, it's no longer being repeatedly written into memory once the game has started. I figured that information may be useful to help troubleshoot the issue.Also, at 8 you say 'It should've been whatever the game intended to set that address to', but I'm not seeing anything up to and including 7 which suggests that you know that the game indeed sets any other value to that address, or is that 7 (i.e. You emulate what the game might do using cheat engine)?The game I tested with was War of the Monsters (NTSC-U). Its ELF file contains a hardcoded value of 43F80000 at address 206E1500.
Once the game has started, I'm expecting address 206E1500's value to change to something different than 43BA0000Why is that? Are you expecting all games to modify this address? What value are you expecting it to be? And importantly - why?My logic is that unless the game modifies this address, it stays as it was. Recall, we cannot unapply a patch, we can only stop applying it, and according to:Cheat Engine can be used to manually-modify 206E1500's value to something else. PCSX2 won't attempt to force it back to 43BA0000.
This suggests that the type 1 patch is no longer being repeatedly written into memory after the game has launchedit indeed doesn't apply it anymore after the game starts.But it's not trying to revert it either - which to me is expected.If you want to check whether or not the 1 bios patch is applied after the game starts, it should be easy: add a place 0 patch for the game crc, e.g. Patch=0,EE,206E1500,extended,12345678, so it's applied once, and if the bios 1 patch overwrites it, then it's a bug, but if it stays 12345678 (or changes to any other value if the game itself writes to that address) then it works as expected, right?
The game I tested with was War of the Monsters (NTSC-U). Its ELF file contains a hardcoded value of 43F80000 at address 206E1500. In the STR, when full booting, 00000000.pnach's hack is causing 43BA0000 to be written to that address after the game's ELF has loaded.OK, so the reason you expect that address to change is because you know that this specific game's elf has a specific value at that address.However, the point where we stop applying the bios patches is before we execute the game's elf entry point. The bios can load the elf into memory at any earlier time maybe do some things after it loads it, etc, and that point in time is still the bios running, therefore it's expected, to me, that the bios patches are still being applied before we actually execute the game elf.But you're splitting hairs here. We now have a very clear point where we consider the bios 'done' and the game starting: that point is just before we execute the elf's entry point.Before that point in time, bios patches would be in effect, and at this point and later - the game's patches are in effect (which you can check with game's crc 0 patches).If this doesn't happen, it could be a bug.If you think we should use another point as the time we switch from 'bios' to 'game', maybe we'll do that, but to be honest, I think we won't.
It really is splitting hairs, and it won't necessarily even be possible.fast booting causes 43BA0000 to be briefly written to address 206E1500 just before the game's ELF is loaded into memoryYes, this indeed happens. The 'bios' in fast boot is mostly an HLE bios, but the real bios is in play too, as you can see briefly at the console's title during fast boot. Since we currently identify all bioses as crc 00000000 then we can't distinguish one bios from another, as well as not able to distinguish fast from full boot before it reaches the elf's entry point - everything before the elf's entry point is 'bios' in this regard, hence bios patches are being applied there.This is unlikely to change.But let's try to look at it from a more practical perspective. If you wanted to patch the bios, I'd think it would be highly unlikely that you'll want to patch the memory into which the game's elf is loaded, right? You'll want to patch the memory where the bios is or which the bios uses, and the patches would not be applied anymore after the game starts, so everything should be great, right? If you want to check whether or not the 1 bios patch is applied after the game starts, it should be easy: add a place 0 patch for the game crc, e.g. Patch=0,EE,206E1500,extended,12345678, so it's applied once, and if the bios 1 patch overwrites it, then it's a bug, but if it stays 12345678 (or changes to any other value if the game itself writes to that address) then it works as expected, right?Before that point in time, bios patches would be in effect, and at this point and later - the game's patches are in effect (which you can check with game's crc 0 patches).If this doesn't happen, it could be a bug.Last night I tried the test you proposed.
It worked fine. When full booting, the BIOS' type 1 patch was overwritten by the game's type 0 patch.If you think we should use another point as the time we switch from 'bios' to 'game', maybe we'll do that, but to be honest, I think we won't. It really is splitting hairs, and it won't necessarily even be possible.IMO, ceasing to write type 1 BIOS patches just prior to when a game's ELF gets loaded into memory would be the only way to completely eliminate the risk of BIOS patches interfering with games. But I have no idea how feasible that would be in practice.But let's try to look at it from a more practical perspective. If you wanted to patch the bios, I'd think it would be highly unlikely that you'll want to patch the memory into which the game's elf is loaded, right?
You'll want to patch the memory where the bios is or which the bios uses, and the patches would not be applied anymore after the game starts, so everything should be great, right?From what I can tell, the widescreen archive's pre-existing BIOS pnaches manipulate memory addresses that are also used by games (sometimes for MIPS instructions - which games can't self-recover from once they begin executing). So with the status quo, depending on the game, type 1 BIOS pnaches can interfere with game memory. Kind of like the opposite scenario to this issue's OP.Having said that, I haven't tried seeing if pre-existing BIOS patches really need to be type 1. For all I know they might work fine with type 0 (which wouldn't have this problem). I could try to test it out if you're interested. Long ago I partially-ported some BIOS widescreen hacks to my PS2's BIOS revision. IMO, ceasing to write type 1 BIOS patches just prior to when a game's ELF gets loaded into memory would be the only way to completely eliminate the risk of BIOS patches interfering with games.
But I have no idea how feasible that would be in practice.Not only its feasibility is questionable, it has one main issues:. Nothing guarantees that the bios doesn't load the game's elf first thing when it starts, and then does whatever else the bios does. This means that all things the bios does after loading the elf to memory would not get the bios patches, in effect defeating its purpose. It might not be the case for some bios versions, or maybe all, but loading the elf into memory is what the bios does. If you don't want to interfere with it - don't patch the bios, or don't bios-patch addresses which the bios loads the elf into.There are also other issues, more technical in nature, such that we need to be able to identify when the bios loads the game into memory - across all bios versions (and any heuristics is also a risk), or that we'll then have three points in time where we change the patches during full boot: 1.
When the bios starts (load bios patches). When the bios loads the game into memory (unload or stop applying all patches). When the game starts (load game patches).Technically, it would be a risk and potential issues we'll be adding for very little value. IMHO it's not worth the effort and risk.But again, most importantly, the main issue is that loading the game into memory is what the bios does (obviously among other things, but still). If you're patching the bios, then you should take that into account.From what I can tell, the widescreen archive's pre-existing BIOS pnaches manipulate memory addresses that are also used by gamesSure. There's not a lot of RAM and all programs use the RAM. Obviously it's possible that some addresses will be used by the bios and then later also by the game once it starts running.However, this should not be an issue.
'used by games' implies that the game is already running. We stop applying the bios patches before the game starts running. The OP was resolved.Then this issue evolved into a discussion about other potential remaining issues with PCSX2's patching system. IMO the only notable remaining one was that type 1 BIOS paches (00000000.pnach) can technically overwrite the memory of a loaded game ELF just prior to execution - which can potentially cause subsequent problems in the game if any of its MIPS instructions or static values were affected.I didn't have anything further to add to 's last reply. But I didn't feel like closing this issue was the best course of action at the time since I still felt like the remaining issue was valid (albeit very tricky).Feel free to close this issue if you consider the remaining issue to be a 'wontfix' kind of thing.
Subreddit of the 21:9 & 32:9 aspect ratio Join us on Discord! Please read the FAQ before posting questions Rules:Rule 1: All posts need to be vaguely connected to 21:9.Rule 2: Don't be a dick. No racism, sexism, personal insults, harassment, etc. Be civil, please.Rule 3: Use original sources for links, credit the OP/OC. Follow it's a good set of basic guidelines for a more cohesive community.Rule 4: No referral links, URL shorteners, or selling used monitors.Rule 5: Read the FAQ before posting new threads.
Topics already answered in the FAQ will be removed.Rule 6: No Box Pictures Related sub-reddits:.Resources:.Filters:. I've had several requests to post the.pnach edits I did for some PS2 games, and after confirming some ways I can keep other.pnach fields intact, I'll be posting them here!.These are all based on their current.pnach files available in the cheatsws.zip, with a line added for 21:9 and disabled 16:9. Just make a folder called 'cheatsws' in your PCSX2 install folder and drop any.pnach files you wish in. It takes priority over the.zip collection.
If for whatever reason you want to switch back to widescreen, delete the '//' in front of the 16:9 and place them in front of 21:9; or delete the.pnach file.Since taking the screenshots for Kingdom Hearts 2 FM+, a patch has come out to make UI elements 16:9 compatible. While I can't edit that, using it on your KH2FM+.iso will make things less stretched when going 21:9. You should patch your game with the English file before applying this patch.