Old Regen pages
Moderator: AamirM
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
I don't care about IPS, UPS, FedEx ... that's up to you if you want to support specific file formats. I'd like to see a system that is unambiguous and easy to create codes more than two bytes in length, such that a code like:King Of Chaos wrote:Have you considered supporting byuu's UPS patching format, in addition to IPS?AamirM wrote:What sort of patching system patching system do you want? (sorry if you mentioned already. I forget things). I think you want something that can inject code in the ROM for things like trainers and/or making hacks to get some unlicensed games work.
Code: Select all
FF0015-5345474121
Code: Select all
FF0010 : 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
--> ** ** ** ** **
FF0010 : 20 20 20 20 20 53 45 47 41 21 20 20 20 20 20 20
I stand corrected. I guess I'll have to start referring to it as the Regen method.King Of Chaos wrote:The Game Genie can only patch ROM, as the Pro Action Replay can technically patch RAM and ROM. I do believe this has been confirmed on the real hardware, via converting a GG code to it's hex address and using it in a PAR.
Maybe I should explain this better. The word at FFD080 is being read then written back unaltered. The original value at FFD080 is 6000. The code FFD081:0060 should change the value to 6060. Currently, Regen changes this into 0060. It seems to be intercepting two bytes instead of one.AamirM wrote:Well now is good time to clear some things up and since now PAR is working correctly, I can say it with more confidence . Also note that I am assuming that PAR intercepted reads and didn't write and this is the way it is done in Regen. I have told this many times but many people have failed to clearly understand this point.TascoDLX wrote:The code FFD081:0060 (not a useful code, mind you) is doing FFD080 = 0060. This should be FFD081 = 60.
If AAAAAA is a RAM addresses, only one byte -- DD -- is intercepted. "Write" may be the wrong terminology but I think we are all aware of what's happening here.AamirM wrote:1) Sik said that AAAAAA:00DD is byte write only. I have already said that Regen doesn't do any writes, so what I thought he meant was that it is only intercepted for byte reads. Maybe I thinked wrong but this is wrong.
No, the value is big-endian. Swapping the bytes would be very wrong. I think that's the main confusion here. When I say FFD080 = 5880, I mean FFD080 = 58 and FFD081 = 80.AamirM wrote:2) As for your above example, you wrote a byte (FFD081 = 60) but when you read a word from there its byte-swapped. Although FFD080:5880 case is not correct indeed. It needs to return 8058. I'll fix it.
And just so we're clear, one more time for the record:
For a PAR code of the format AAAAAA:DDDD...
If AAAAAA is a ROM address, (AAAAAA).W = DDDD.
AAAAAA should always be even. Odd addresses here are invalid.
If AAAAAA is a RAM address, then...
- If AAAAAA is even and DDDD is less than or equal to 00FF, (AAAAAA).B = DD [high byte is ignored]
- If AAAAAA is even and DDDD is greater than 00FF, (AAAAAA).W = DDDD
- If AAAAAA is odd, (AAAAAA).B = DD [high byte should probably be ignored]
That's the problem, "filtro pasa bajo" has nothing to do with the real meaning. Through "saturación" seems like a good translation for overdrive...Shiru wrote:Absolutely don't know spanish, but I guess that Lowpass is 'Filtro pasa bajo' and overdrive is 'Saturación' (according to multi-language articles in Wikipedia).
It does, because it isn't using just the standard 7-bit ASCII enconding o_o' Through I've sent it as the body of the e-mail (I wonder if you wanted an attached file), and I guess it became UTF-8 automatically there anyways.AamirM wrote:One thing I forgot to mention was that you need to post it in UTF-8 encoding. Doens't matter for spanish though I think.
No, the size has absolutely nothing to do with the address. The patch size is determined by the value of the data (< 0x100 is byte, word otherwise) and nothing more. Address has nothing to do with it. It's like when people say that PAR codes must start with FF (meaning they only work in RAM). This isn't true.TascoDLX wrote:If AAAAAA is a RAM addresses, only one byte -- DD -- is intercepted. "Write" may be the wrong terminology but I think we are all aware of what's happening here.AamirM wrote:1) Sik said that AAAAAA:00DD is byte write only. I have already said that Regen doesn't do any writes, so what I thought he meant was that it is only intercepted for byte reads. Maybe I thinked wrong but this is wrong.
Sik is pronounced as "seek", not as "sick".
Once again...Sik wrote:No, the size has absolutely nothing to do with the address. The patch size is determined by the value of the data (< 0x100 is byte, word otherwise) and nothing more. Address has nothing to do with it. It's like when people say that PAR codes must start with FF (meaning they only work in RAM). This isn't true.TascoDLX wrote:If AAAAAA is a RAM addresses, only one byte -- DD -- is intercepted. "Write" may be the wrong terminology but I think we are all aware of what's happening here.AamirM wrote:1) Sik said that AAAAAA:00DD is byte write only. I have already said that Regen doesn't do any writes, so what I thought he meant was that it is only intercepted for byte reads. Maybe I thinked wrong but this is wrong.
FFF000:005A ensures that (FFF000).B == 5A
00F000:005A ensures that (00F000).W == 005A
It seems the address has a little something to do with it.
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
Well, addresses that start with FF are the typical PAR RAM patches. Any addresses starting with 00 is a ROM patch converted from a Game Genie code. Example, AW1A-AA0A converts to 00AEC0:6004 which does work in a real PAR as a ROM patch.
If anyone has noticed, Kega automatically converts Game Genie codes into their hex ROM patch format.
If anyone has noticed, Kega automatically converts Game Genie codes into their hex ROM patch format.
Last edited by King Of Chaos on Fri Apr 18, 2008 8:59 pm, edited 1 time in total.
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States
Alright. That certainly clears things up. Game Genie codes affect ROM, PAR codes affect RAM.King Of Chaos wrote:Well, addresses that start with FF are the typical PAR RAM patches. Any addresses starting with 00 is a ROM patch converted from a Game Genie code. Example, AW1A-AA0A converts to 00AEC0:6004 which does work in a real PAR as a ROM patch.
But my previous statement still holds true for Kega PAR codes -- even if they're not *real* PAR codes.
PAR codes work in any address. Same with Game Genie, but its implementation in the real hardware only allowed it to work on the ROM. In their most raw form, PAR and GG codes are just an address:data system with no weird limitations at all.Sik wrote:It's like when people say that PAR codes must start with FF (meaning they only work in RAM). This isn't true.
EDIT: and I've used word patches to RAM in Sonic 3D in Kega (hacking test) and it worked perfectly. So you're wrong in that too.
Sik is pronounced as "seek", not as "sick".
All I'm saying is that, as far as PAR codes go, Kega clearly isn't following the rules (that you have stated), which is why I desire a better implementation. (BTW, I think you just replied to your own quote -- blew my mind!)Sik wrote:PAR codes work in any address. Same with Game Genie, but its implementation in the real hardware only allowed it to work on the ROM. In their most raw form, PAR and GG codes are just an address:data system with no weird limitations at all.Sik wrote:It's like when people say that PAR codes must start with FF (meaning they only work in RAM). This isn't true.
I hope that wasn't directed at me because I never claimed the contrary.Sik wrote:EDIT: and I've used word patches to RAM in Sonic 3D in Kega (hacking test) and it worked perfectly. So you're wrong in that too.
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States