 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in SMW Hacking. |
| User | Post |
| rubixcuber Posts: 159/356 |
I didn't have a cape in any of the emulators. And the rom was expanded by Lunar Expand. |
| MathOnNapkins Posts: 843/1106 |
.... what the hell. I replaced $506C though $5075 (btw the 0x4E6E did not make any sense to me, even if you did have a headered rom) with NOPs, and then proceded to overwrite the $5075 with EE DF 0B (INC $0DBF). Different approach, but a success in all three emulators mentioned here. Coin counter was incremented every time I pressed X or Y buttons. However, first things first, I did do the research to see what i was modifying through smwcentral. Is it possible in the different emulators you did not possess a cape in the non Snes9x emulators while playing? This code only triggers if powerup == 2, i.e. having a cape.
The only other thing I can think of is that this is an issue with how you expanded the rom. However, Snes9x is actually more restrictive of badly sized roms than the other emulators, so that doesn't seem to be the answer, at least initially. Care to provide any more details b/c I'm stumped as to what could be the cause. More information would be needed. |
| MathOnNapkins Posts: 840/1106 |
I dunno... there has to be something timing related going on here. Or perhaps a read/write access violation. I'll check this out when I get home and test out what you described on the real thing. |
| rubixcuber Posts: 153/356 |
Yep, made sure of all of that. I tried the BRK. I put the BRK in the routine and nothing changed on ZSNES, but it executed the BRK on Snes9x if you hit X/Y. I put a break in the routine which I added the jump to (which is original SMW code) and on ZSNES... still nothing happened. Perhaps Snes9x and ZSNES handle controller input differently enough that different routines get called? |
| HyperHacker Posts: 3535/5072 |
In that case it might be worth putting a BRK at the beginning of the routine, or in place of the branch that should be calling it, and seeing if it ever even gets executed.
You did ensure everything is set up the same though, right? No hacks enabled, same ROM and SRAM, no save states, and no auto-patched IPS patches? |
| rubixcuber Posts: 151/356 |
Yeah, I'm pretty sure they are right, but I want to know why they behave differently and how I can fix it. With any luck I'll figure it out on my own eventually.
I tried LDA, INC, STA from 7E with the same results. Works on Snes9x, not on ZSnes/BSnes. |
| HyperHacker Posts: 3531/5072 |
Well if there isn't then just do it manually (LDA, INC, STA, possibly a PHA and PLA if need be).
Also if both ZSnes and BSnes (the most accurate emulator yet) do the same thing, it's probably fairly safe to assume they're right. |
| rubixcuber Posts: 150/356 |
There isn't an INC, long in the 65816 instruction set is there? And anyways INC $0DBF works and I've had all sorts of different code there that doesnt seem to work. Here's exactly what I've done:
At x4E6E I've added a JSL to a routine I wrote. As of now the routine does only this: INC $0DBF RTL In Snes9x the coin counter increments each time this routine is called. I'm not really sure what ZSNES/BSNES are doing... |
| HyperHacker Posts: 3523/5072 |
Well like I said it doesn't matter anyway, unless you're really really short on space and can save a lot by compressing routines and decompressing them to SRAM there isn't much point. (And chances are graphics would be better used for that, because they'd compress better.) It is important that your hacks work on real hardware. but this specific hack has no purpose I can think of on a SNES, so there's no point testing it.
As for your problem, try INC $7E0DBF. Could be some problem with the way one of the emulators handles the data bank register. |
| rubixcuber Posts: 134/356 |
As I said, there's only an increment of number of coins. INC $0DBF or EEBF0D. That's it. That is all the code I have written (after reverting to a backup). On Snes9x this gets executed and increments the number of coins. On ZSNES I have to assume this gets executed and... does I don't know what. This increment is just inserted into an existing SMW routine. I'll edit in which one and where it is when I get home later.
And, yeah, I did mean $700000. And that's what I meant about not knowing if it works on a real SNES. WRAM and SRAM are different, but as far as executing code in an emulator I think they both work just fine. I'll run some more tests when I get home. |
| MathOnNapkins Posts: 837/1106 |
Well I would have loved to help you more but you didn't even post any code so don't expect much in that way. Just b/c it doesn't work on BSNES and ZSNES doesn't mean the code is faulty. Trying it out on a real snes would be the best way to check. But again you posted no code so you left us guessing.
Regarding executing from SRAM: I'm pretty sure you meant LDA #$6B STA $700000 JSL $700000 Otherwise we're talking about executing from WRAM, which is known to work. The SRAM, being of a different type of RAM, might be questionable in that regard. |
| rubixcuber Posts: 127/356 |
Ok, but the works on a real SNES was about HyperHackers SRAM question, not about my problem. Executing SRAM works fine on any emulator, but I have no idea if it works on a real SNES. I have no idea if any of the hacks posted here work on a realy SNES. That's all I meant. |
| Stifu Posts: 529/647 |
Originally posted by rubixcuber Of course. Even if no one plays your hack on a real console, it still matters. Emulators are obviously modeled after real consoles, so if your stuff doesn't work on a real console but works with certain emulators, then those emulators are wrong. And if they're wrong, they may get corrected afterward, resulting in your hack not working properly anymore... Besides, it's not like there's any drawback to programming something properly so it works on real hardware and with accurate emulators. |
| rubixcuber Posts: 126/356 |
Hyperhacker: On a real SNES? I have no idea. You didn't say anything about a real SNES. Do we care if it works on a real SNES? I haven't looked at GB in a while, but I think you could execute code in RAM in the same fashion.
MathOnNapkins: Did you read my posts? I edited out all reference to controller data at all. I just have an INC statement incrementing the number of coins. On ZSNES coins stay put, on Snes9x coins increment. All code referencing controller data is the original SMW code. |
| HyperHacker Posts: 3514/5072 |
Those addresses should be in the SMW memory map at SMWCentral.
Originally posted by rubixcuber That doesn't ensure it works on a real SNES, unless you tried it on one. But when I asked that I was thinking Game Boy (where putting code in SRAM could be a nice way to make it accessible from any ROM bank) as opposed to SNES (where SRAM is in its own bank anyway), so it's probably not really useful.  |
| MathOnNapkins Posts: 833/1106 |
First, I'm assuming you're trying to read from the parallel controller registers at $4218 - $421F or the serial registers (forget their addresses). Second, I'm going to assume you are reading them outside of V-blank. That's likely.
The data from the controllers is only supposed to be available after so many cycles of V-blank. After V-blank ends the data becomes random static pretty much. Has to be a flaw of Snes9x, it's too lenient on controller input and when it can be read. This doesn't change the fact that you were trying to do something illegal though. However, almost any game for the SNES will buffer this data into it's own memory space so try to find those WRAM addresses and use them. |
| rubixcuber Posts: 116/356 |
Well, I tried BSNES and it doesnt work there, so I guess I'm going to rewrite my powerup engine. Thanks for the suggestions. |
| Stifu Posts: 526/647 |
Personally, although bsnes isn't perfect, it's so accurate that I'd take it as the ultimate reference about whether your hack works right or not, unless you can test your stuff on real hardware (flash cart or other units).
In other words, if it works fine with bsnes, whatever about the other emulators, as there are very strong chances they're wrong if they don't behave the same... and if they're good/popular emulators, they'll get fixed later. |
| rubixcuber Posts: 110/356 |
Absolutely sure it's the right file. I've started making changes to something else each time and making sure those changes show up in both emulators and they do. No other roms or ips files in the directory. I've never had a problem like this before.
SRAM is executable. (I ran a test to make sure) If you do say: LDA $#6B STA $00 JSL $000000 It will run 6B (RTL) and return. |
| HyperHacker Posts: 3504/5072 |
Are you sure you loaded the right file, and are there any IPS patches with the same name as your ROM that might be getting automatically applied by the emulator?
BTW, random ASM question since I'm here (it'd kind of on topic ): Is SRAM executable? Can I just load a bunch of code into it and run it? |
| This is a long thread. Click here to view it. | |
