Sega Megadrive/Genesis development
http://gendev.spritesmind.net/forum/
I don't care about IPS, UPS, FedExKing 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.
... 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:
Code: Select all
FF0015-5345474121Code: 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 20I 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 confidenceTascoDLX wrote:The code FFD081:0060 (not a useful code, mind you) is doing FFD080 = 0060. This should be FFD081 = 60.. 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.
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.
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.
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.
Unless the ROM is 64KB, that is XDAlright. 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.
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.
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.