|
|
Post by elmer on Nov 1, 2019 23:45:31 GMT
Thank you very much! Another question. Can I use a program like Lunar IPS to patch the two SSC ROMs? At first I thought the download links were the entire ROMs pre-patched, but the file sizes were too small. Yes you need to use a patching program to apply those files, but no, not LunarIPS. From my "Programming Resources" thread ... To use the patch, just apply the xdelta patch to a US Super System Card image and then copy the newly patched image to your TED2's SD card. You should see the old System Card version number replace with "TED2" and the new patch version number. Current Patch Version 3.01 - Initial version Patch file for USA System Card 3.0 (in xdelta3 format) ... www.dropbox.com/s/zcz384fj47xu84u/TED2%20System%20Card%203.01%20USA.xdelta?dl=1Patch file for JPN System Card 3.0 (in xdelta3 format) ... www.dropbox.com/s/nuctz90ra9aoo3k/TED2%20System%20Card%203.01%20JPN.xdelta?dl=1An xdelta3 patching utility from romhacking.net that is know to work and be easy to use ... www.romhacking.net/utilities/704/ |
|
pokun
Gun-headed
Posts: 85 
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 2, 2019 10:32:10 GMT
What kind of experiments do you wish to run? Do you really just want to see your US HuCard games fail to run ... it's not very exciting, y'know, there aren't any messages or anything, the game just soft-locks. Yes I know exactly how the region lockout works. If you really need a practical example I would like to make a test program that shows one screen if it works and another if it doesn't as a demonstrational program using the exact lockout code used in non-Japanese games. It would be nice to use the Everdrive to test it on real hardware, but the current Everdrive won't let me do that. Another practical example would be to test a region mod (the mod of input port K bit 6, not the pin swap mod) using the Everdrive if you don't have any non-Japanese HuCards. Found it. I have no idea if any games actually do fail though: ... And I found the byte sequence that he is using for removing the US protection... it's much longer than needed, and looks like it will fail to remove the protection on some games. Now ... one thing that has been know to fail, especially with early TurboEverdrives, is the fugly hardware region-free solutions that actually alter the electronics of the console, and effect the bus timings. Now that is what I, personally, call a "hacky" solution. IMHO, runtime patching is an elegant solution in comparison. I can only agree, if you change the hardware so it becomes out of spec you are just asking for compatibility problems. Using the Everdrive to play non-Japanese games with, is a good way to avoid hardware mods. All I want is for each patch to be disableable (I mean the region patch could be globally enabled/disabled and resolution patches could have their own global setting and so on). The Everdrives are still full of poor documentation and often hacky solutions though. The TurboEverdrive only has a readme file that only tells you what OS file to use (which doesn't even seems to exist). And as Shadoff said it doesn't say anywhere that games are region patched and there are no warnings. People only know it because they have followed the development of it from start, but it's impossible for new users to know how it works. This is a highly philosophical question and I can see that you don't share that view with me and requires practical examples. So if you are not convinced let's just leave it as a feature request from me: To make any automatic runtime patches (except system card patch) being optional with some kind of user-accessible setting (even a config file or something would be fine if adding menu options are too much trouble). If you are in two minds, and you know there are people like me that prefer to have full control, you might as well just make it optional and keep everyone happy.  |
|
|
|
Post by dshadoff on Nov 2, 2019 12:07:50 GMT
What kind of experiments do you wish to run? Do you really just want to see your US HuCard games fail to run ... it's not very exciting, y'know, there aren't any messages or anything, the game just soft-locks. Yes I know exactly how the region lockout works. If you really need a practical example I would like to make a test program that shows one screen if it works and another if it doesn't as a demonstrational program using the exact lockout code used in non-Japanese games. It would be nice to use the Everdrive to test it on real hardware, but the current Everdrive won't let me do that. Another practical example would be to test a region mod (the mod of input port K bit 6, not the pin swap mod) using the Everdrive if you don't have any non-Japanese HuCards. You can still do that. The only thing is that you shouldn't use the 13-byte sequence that the Everdrive is searching for (i.e. switch the sequence of 2 opcodes that aren't required to be sequential). If elmer is not using the same 13-byte sequence to check, we can ask him for what sequence he is searching for, and use a slightly different sequence which doesn't trigger the patch, yet still provides the raw information. Heck, this could even be put into HuC if it was thought to be truly useful. Found it. I have no idea if any games actually do fail though: ... And I found the byte sequence that he is using for removing the US protection... it's much longer than needed, and looks like it will fail to remove the protection on some games. OK, shortly after I posted that, I did a full re-rip and analysis of all US HuCards (I am pretty sure I also posted in the same thread, but just in case I didn't...). As it turns out, they all use the same code sequence with a couple of exceptions... which turn out to the cards that aren't protected in the first place. So, there aren't any official releases which fail to have the protection removed. The reason elmer was asking for an example is to find out whether (a) any second-pressing of a game might have altered the sequence, or (b) whether some game that wasn't specifically tested in my analysis is missed. In my original statement, I only spoke of the theoretical possibility of failure, from which I then confirmed that all of the official US releases were indeed safe. As I mentioned above, however, as long as you use a slightly adjusted method of checking, you can intentionally avoid this patch. The Everdrives are still full of poor documentation and often hacky solutions though. The TurboEverdrive only has a readme file that only tells you what OS file to use (which doesn't even seems to exist). And as Shadoff said it doesn't say anywhere that games are region patched and there are no warnings. People only know it because they have followed the development of it from start, but it's impossible for new users to know how it works. This is a highly philosophical question and I can see that you don't share that view with me and requires practical examples. So if you are not convinced let's just leave it as a feature request from me: To make any automatic runtime patches (except system card patch) being optional with some kind of user-accessible setting (even a config file or something would be fine if adding menu options are too much trouble). If you are in two minds, and you know there are people like me that prefer to have full control, you might as well just make it optional and keep everyone happy. Hmm... it's true that the Everdrive is a bit lacking in the documentation department - this is one of the reasons that elmer and I started discussing about features several months ago, and which spurred me to do a partial disassembly and him to embark on creating the new version. He is already addressing issues like how the Populous cartridge has issues with the original Everdrive for example. The fact that nobody actually knew that the US games were auto-patched speaks to its utility: if this patching were to be removed, I can see that the primary support question would likely be "why doesn't your version it work for my <xxx> image ?", so retaining this functionality would - in my opinion - reduce confusion. But we can create a region-detection byte sequence to be used which circumvents the Everdrive check. For the second category of auto-patches - system card bus conflict checks - I feel that this is also useful enough that it should be automatic... but this could become complicated to automate, based on the number of different system card patches I have seen; it may be difficult in some cases to recognize whether the base ROM is the system card image or not. For any other patches, I share your opinion. I wouldn't want the card to automatically patch R-Type without my instructions, as I might be attempting an A/B test on it. But I also wouldn't ask to put user interface elements in to ask the user whether they want to control this... that's not really as easy as it sounds (possible ? yes. Pain in the backside ? also yes.). I personally would do one of two things: (a) require the user to patch their own games for hack/visual/translation type things, or (b) at best, *possibly* add a patches directory search for applying patches on a future version (not the initial one), but even this is potentially contentious because of patch format issues. |
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 2, 2019 15:31:11 GMT
You can still do that. The only thing is that you shouldn't use the 13-byte sequence that the Everdrive is searching for (i.e. switch the sequence of 2 opcodes that aren't required to be sequential). If elmer is not using the same 13-byte sequence to check, we can ask him for what sequence he is searching for, and use a slightly different sequence which doesn't trigger the patch, yet still provides the raw information. Part of the point of it is to use the exact same region lockout code as commercial games use, so that it IS caught by region auto-patchers such as the Everdrive's. And to test that properly the Everdrive would need to be able to enable and disable the patching. OK, shortly after I posted that, I did a full re-rip and analysis of all US HuCards (I am pretty sure I also posted in the same thread, but just in case I didn't...). As it turns out, they all use the same code sequence with a couple of exceptions... which turn out to the cards that aren't protected in the first place. So, there aren't any official releases which fail to have the protection removed. The reason elmer was asking for an example is to find out whether (a) any second-pressing of a game might have altered the sequence, or (b) whether some game that wasn't specifically tested in my analysis is missed. In my original statement, I only spoke of the theoretical possibility of failure, from which I then confirmed that all of the official US releases were indeed safe. Ah I see, if you did I missed that. Thanks for confirming this, it is like I've previously heard. Now I'm just curious if you happen to have a list of games that doesn't enforce region lockout? The only game I ever heard of not doing it is Klax, but it sounds like there are more than one. The fact that nobody actually knew that the US games were auto-patched speaks to its utility: if this patching were to be removed, I can see that the primary support question would likely be "why doesn't your version it work for my <xxx> image ?", so retaining this functionality would - in my opinion - reduce confusion. But we can create a region-detection byte sequence to be used which circumvents the Everdrive check. My request was to make it optional, not remove it. It could even be enabled by default to reduce confusion. Also a readme file would take care of other confusion and reduce the most common support questions. The SD2SNES has the exact same type of region patching and I don't think it has stumped people much (although the SNES games enforcing it actually do have a region lockout screen with text explaining the problem). For the second category of auto-patches - system card bus conflict checks - I feel that this is also useful enough that it should be automatic... but this could become complicated to automate, based on the number of different system card patches I have seen; it may be difficult in some cases to recognize whether the base ROM is the system card image or not. I agree with you here, and I think I said so. It's just unfortunate that that such bus conflicts may happen. But I also wouldn't ask to put user interface elements in to ask the user whether they want to control this... that's not really as easy as it sounds (possible ? yes. Pain in the backside ? also yes.). Yeah I know how troublesome it is to make interfaces. That's why I suggested to just save it on a text file and let the user edit it on a computer. Although this of course still requires accessing the SD card file system. I don't think we are the only ones wanting this. |
|
|
|
Post by dshadoff on Nov 2, 2019 16:32:15 GMT
You can still do that. The only thing is that you shouldn't use the 13-byte sequence that the Everdrive is searching for (i.e. switch the sequence of 2 opcodes that aren't required to be sequential). If elmer is not using the same 13-byte sequence to check, we can ask him for what sequence he is searching for, and use a slightly different sequence which doesn't trigger the patch, yet still provides the raw information. Part of the point of it is to use the exact same region lockout code as commercial games use, so that it IS caught by region auto-patchers such as the Everdrive's. And to test that properly the Everdrive would need to be able to enable and disable the patching. OK, now you've completely lost me. Please explain in more detail what you're trying to actually accomplish, and what you think is going to go wrong. 1) If you use the *exact* code, it will recognize the system's region and go to a white screen, and the Everdrive will circumvent that. Which is the whole point, and I see no value to the white screen... 2) If you use a slightly adjusted code, it will recognize the system's region, and allow you to program alternate code paths, and the Everdrive will not circumvent that (although I have seen rare hardware hacks which circumvent the actual region detection mechanism). I should note that - if I recall correctly - the exact byte code sequence includes the infinite loop, which is what you said you didn't want in the original post. OK, shortly after I posted that, I did a full re-rip and analysis of all US HuCards (I am pretty sure I also posted in the same thread, but just in case I didn't...). As it turns out, they all use the same code sequence with a couple of exceptions... which turn out to the cards that aren't protected in the first place. So, there aren't any official releases which fail to have the protection removed. The reason elmer was asking for an example is to find out whether (a) any second-pressing of a game might have altered the sequence, or (b) whether some game that wasn't specifically tested in my analysis is missed. In my original statement, I only spoke of the theoretical possibility of failure, from which I then confirmed that all of the official US releases were indeed safe. Ah I see, if you did I missed that. Thanks for confirming this, it is like I've previously heard. Now I'm just curious if you happen to have a list of games that doesn't enforce region lockout? The only game I ever heard of not doing it is Klax, but it sounds like there are more than one. There were 2 or 3, but I don't seem to have my notes handy. I thought I had posted it on this board as well, but I also can't seem to find that. And if I recall correctly, Klax actually did enforce lockout, based on the original card. You probably won't find out based on ROM images found on the internet, because most of them are already pre-patched to remove the protection... The fact that nobody actually knew that the US games were auto-patched speaks to its utility: if this patching were to be removed, I can see that the primary support question would likely be "why doesn't your version it work for my <xxx> image ?", so retaining this functionality would - in my opinion - reduce confusion. But we can create a region-detection byte sequence to be used which circumvents the Everdrive check. My request was to make it optional, not remove it. It could even be enabled by default to reduce confusion. Also a readme file would take care of other confusion and reduce the most common support questions. The SD2SNES has the exact same type of region patching and I don't think it has stumped people much (although the SNES games enforcing it actually do have a region lockout screen with text explaining the problem). In my experience, a lot of people try using things and don't read the notes properly. Then they go asking questions which have already been answered. I think this request would be more trouble than it's worth, even if there were a legitimate use case (of which I am not yet convinced). |
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 2, 2019 17:27:48 GMT
Part of the point of it is to use the exact same region lockout code as commercial games use, so that it IS caught by region auto-patchers such as the Everdrive's. And to test that properly the Everdrive would need to be able to enable and disable the patching. OK, now you've completely lost me. Please explain in more detail what you're trying to actually accomplish, and what you think is going to go wrong. 1) If you use the *exact* code, it will recognize the system's region and go to a white screen, and the Everdrive will circumvent that. Which is the whole point, and I see no value to the white screen... 2) If you use a slightly adjusted code, it will recognize the system's region, and allow you to program alternate code paths, and the Everdrive will not circumvent that (although I have seen rare hardware hacks which circumvent the actual region detection mechanism). I should note that - if I recall correctly - the exact byte code sequence includes the infinite loop, which is what you said you didn't want in the original post. Did I say that? Anyway in this example it would be needed, and you seems to understand it correctly so I don't think there is anything more to explain? The only purpose it has is to work as I just described. As for what could go wrong, any change to any ROM may theoretically break something in some situation. In the scope of homebrew a ROM could contain anything and isn't limited to just licensed and unlicensed games. And that is mostly why I include optional region patching in my request. |
|
|
|
Post by dshadoff on Nov 2, 2019 17:53:27 GMT
I'm still not catching it, you'll need to provide more detail.
If you are:
1) building homebrew, and
2) want it to identify the console, and
3) if you even still want it to go into an infinite white-screen loop like the USA cards did on original hardware with converters, and
4) if you want to be sure that the Everdrive will not auto-patch...
-> just take the original detection byte-sequence and add a NOP ($EA) anywhere between the LDA $1000 and the conditional branch.
This will override the auto-patch system on all versions of the Everdrive, and any other system.
...And you can be sure that soon after release, somebody will create a patch to prevent the region detect mechanism (unless you choose to do something easter-egg like with it).
...And if you want it in there ONLY for the purposes of debugging up until the final release, make the NOP conditional with #ifdef
If you are doing home-brew, you already have full control.
|
|
|
|
Post by elmer on Nov 2, 2019 18:16:56 GMT
Ah I see, if you did I missed that. Thanks for confirming this, it is like I've previously heard. Now I'm just curious if you happen to have a list of games that doesn't enforce region lockout? The only game I ever heard of not doing it is Klax, but it sounds like there are more than one. Yes I know exactly how the region lockout works. If you really need a practical example I would like to make a test program that shows one screen if it works and another if it doesn't as a demonstrational program using the exact lockout code used in non-Japanese games. I'm sorry, but as Dave said, if you choose to use "the exact lockout code used in non-Japanese games", then on failure the test jumps to code in bank $90 ... which isn't in HuCard memory space, and you can't put any code there to display your alternate screen display, and your example doesn't work. Now, if you just wish to display one screen on a TurboGrafx, and a different screen on a PCE, and use the port bit to figure out which is which, then sure, we can absolutely agree that the Turbo Everdrive shouldn't get in the way and just patch your code out ... and Krikzz's code won't do that. I've already posted the detection/patching code that I'm currently using, and it is both more, and less specific than Krikzz's routine. For either sets of code, you're extremely unlikely to ever get a false-positive in any reasonable-use case, whatever a homebrew programmer is trying to do ... but I could certainly add a few extra detection-bytes to my code to make it even less susceptible to someone's deliberate attempts to manufacture a "problem". Anyway, here's my current code ... pcengine.proboards.com/post/8860/thread |
|
|
|
Post by Mathius on Nov 3, 2019 0:01:18 GMT
Thank you very much! Another question. Can I use a program like Lunar IPS to patch the two SSC ROMs? At first I thought the download links were the entire ROMs pre-patched, but the file sizes were too small. Yes you need to use a patching program to apply those files, but no, not LunarIPS. From my "Programming Resources" thread ... To use the patch, just apply the xdelta patch to a US Super System Card image and then copy the newly patched image to your TED2's SD card. You should see the old System Card version number replace with "TED2" and the new patch version number. Current Patch Version 3.01 - Initial version Patch file for USA System Card 3.0 (in xdelta3 format) ... www.dropbox.com/s/zcz384fj47xu84u/TED2%20System%20Card%203.01%20USA.xdelta?dl=1Patch file for JPN System Card 3.0 (in xdelta3 format) ... www.dropbox.com/s/nuctz90ra9aoo3k/TED2%20System%20Card%203.01%20JPN.xdelta?dl=1An xdelta3 patching utility from romhacking.net that is know to work and be easy to use ... www.romhacking.net/utilities/704/Thank you. I don't know how I missed that, but, well.....you know. |
|
|
|
Post by elmer on Nov 3, 2019 20:36:15 GMT
Thank you. I don't know how I missed that, but, well.....you know. Sorry I couldn't just upload a fully-patched version ... I don't want to open up this forum (or the old PCEFX) to claims of copyright-violation. As it is, when it's finally released, TEOS will just patch the System Card itself to avoid the issue. For the second category of auto-patches - system card bus conflict checks - I feel that this is also useful enough that it should be automatic... but this could become complicated to automate, based on the number of different system card patches I have seen; it may be difficult in some cases to recognize whether the base ROM is the system card image or not. Hmmm ... what other System Card patches have you seen? I wasn't aware that there are already a bunch of patched versions going around! For any other patches, I share your opinion. I wouldn't want the card to automatically patch R-Type without my instructions, as I might be attempting an A/B test on it. Yeah, OK, you and pokun have convinced me. Automatic patches should normally only be to fix things that break with the Turbo Everdrive. |
|
|
|
Post by dshadoff on Nov 3, 2019 21:28:19 GMT
For the second category of auto-patches - system card bus conflict checks - I feel that this is also useful enough that it should be automatic... but this could become complicated to automate, based on the number of different system card patches I have seen; it may be difficult in some cases to recognize whether the base ROM is the system card image or not. Hmmm ... what other System Card patches have you seen? I wasn't aware that there are already a bunch of patched versions going around! In addition to the bus-conflict fix that you made, you and I worked together on a couple of font-related ones. 1) Earlier this year (or maybe late last year ?) we worked on a patch for a more legible 12x12 english font for the system card (to fix Exile) 2) We also worked on an extension to the System Card to help make translations easier (8x12 font with helper functions). 3) Chris Covell had made a special patch to the System Card which adds PCEMon I'm pretty sure there are others as well... just not at top of mind right now. |
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 4, 2019 16:11:50 GMT
I'm still not catching it, you'll need to provide more detail. If you are: 1) building homebrew, and 2) want it to identify the console, and 3) if you even still want it to go into an infinite white-screen loop like the USA cards did on original hardware with converters, and 4) if you want to be sure that the Everdrive will not auto-patch... I'm not trying make my games region protected if that's what people think. Making things on retro systems is already obscure as it is, no need to reduce the number of possible players even further. It's just a demo that uses the official lockout code and does not do much else but display a screen that the lockout didn't happen. Any attempts to fix the "problem" would probably break the rules that I arbitrarily set for the demo. It's a theoretical demo with no purpose. Although I guess it could be used for educational purposes or something. Ah I see, if you did I missed that. Thanks for confirming this, it is like I've previously heard. Now I'm just curious if you happen to have a list of games that doesn't enforce region lockout? The only game I ever heard of not doing it is Klax, but it sounds like there are more than one. Yes I know exactly how the region lockout works. If you really need a practical example I would like to make a test program that shows one screen if it works and another if it doesn't as a demonstrational program using the exact lockout code used in non-Japanese games. I'm sorry, but as Dave said, if you choose to use "the exact lockout code used in non-Japanese games", then on failure the test jumps to code in bank $90 ... which isn't in HuCard memory space, and you can't put any code there to display your alternate screen display, and your example doesn't work. Now, if you just wish to display one screen on a TurboGrafx, and a different screen on a PCE, and use the port bit to figure out which is which, then sure, we can absolutely agree that the Turbo Everdrive shouldn't get in the way and just patch your code out ... and Krikzz's code won't do that. I've already posted the detection/patching code that I'm currently using, and it is both more, and less specific than Krikzz's routine. For either sets of code, you're extremely unlikely to ever get a false-positive in any reasonable-use case, whatever a homebrew programmer is trying to do ... but I could certainly add a few extra detection-bytes to my code to make it even less susceptible to someone's deliberate attempts to manufacture a "problem". Anyway, here's my current code ... pcengine.proboards.com/post/8860/threadAh there it is! Thanks for the link! I think the demo would work, that blank screen would be that other screen. If you want to display something more interesting, I imagine that you can escape the blank screen using a TIMER interrupt or something. At least if you only use the 6 necessary bytes for the lockout mechanism. If you use the full 25 bytes however, it includes a SEI so interrupts can't be used. That said, I looked more into the lockout code now and it appears that I lied when I said that I fully understand it. I have no idea what happens when it jumps to $4000 in non-existing block $90. Supposedly a blank screen and a freeze, but is the state of the hardware at that point even predictable? If not, then I guess there is no reliable way to escape that "screen". Anyway it doesn't seem like neither of you are going to be convinced and are just looking for practical problems and solutions rather than theoretical ones, so I'm going to leave this. You know that if you ever decides to implement option settings in the software there is an interest for having the region patching optional. It appears Elmer is convinced not to force resolution patches, which is what I was more concerned about as it has practical use (like A/B comparing like Shaddoff said). The region thing is just philosophical. |
|
|
|
Post by dshadoff on Nov 4, 2019 16:32:12 GMT
Actually, what we are saying is that even the theoretical problems have straightforward solutions which don’t rely on using an exact copy of code which does nonsensical things. It is perfectly easy to check the region without resorting to copying that fixed nonsense sequence.
|
|
|
|
Post by elmer on Nov 4, 2019 20:04:46 GMT
It appears Elmer is convinced not to force resolution patches, which is what I was more concerned about as it has practical use (like A/B comparing like Shaddoff said). Just remember ... it wouldn't be a "resolution" patch, just a sprites-per-line patch to undo a paranoid change that NEC management forced on Hudson, that degraded the US all-in-one version of R-Type in comparison to the Japanese split-HuCards version. Generally, from a gamer's POV, they're going to assume that the later all-in-one version is the more modern, and better version of the game. Anyway, it's easy to patch the HuCard image, rather than have the Everdrive do it, so it's basically a non-issue. For anyone that actually has an Everdrive, and wants to see what the US version of R-Type would look like with the sprites-per-line limit removed, they can just edit the HuCard image and change the byte at offset $1501 from $0A to $00. |
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 4, 2019 22:43:37 GMT
I understand, thank you!
|
|
