(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-19-24 11:17 AM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - Mess up Morton and Roy's walls (SMW)
  
User name:
Password:
Reply:
 
Options: - -
Quik-Attach:
Preview for more options

Max size 1.00 MB, types: png, gif, jpg, txt, zip, rar, tar, gz, 7z, ace, mp3, ogg, mid, ips, bz2, lzh, psd

UserPost
calcwatch
Posts: 1/7
Originally posted by spel werdz rite
Calculation:

As for finding out how many digits that is, when you take 2^n it will increase one more decimal every three or four times. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384
It increases in that pattern for a while, that basically boils down to 3.33 times to increase a digit. (it's not exact, but it's close)
So to find the number of digits, it would be 1048576/3.33=314572.8 which rounds up to 314,573 digits.


Not to beat a dead horse, but...

[math] In case you're curious, the number of times to increase a digit is 1/log(2) which is about 3.322 -- but I like your approximation method ...
To get the number of digits exactly, take 1+log(2^1048576) (which is equivalent to 1+1048576*log(2)) and round the result down. So I get 315,653 digits -- pretty darn close to what you got, though. [/math]

Getting back to ROM hacking, didn't someone already set up a database for SMW addresses (or was it just for commenting the assembly code)?... I remember seeing a link to one ("Open Source SMW" or something like that) in the last incarnation of these forums, but I guess it didn't really catch on?...
BMF54123
Posts: 129/876
I usually specify which addresses my hacks use in their READMEs, just in case a conflict arises. I should've known $7E010B was already claimed.

Technically, $7E0100-$7E01FF is the stack, but SMW doesn't even use 1/4 of the space. Just to be on the safe side, I wouldn't go past $7E0180, but that still leaves you with over 100 bytes of free, uninitialized (i.e. never cleared) LowRAM. Hello, absolute addressing!

I've also found a few more spots of free RAM in the first 8K. There are a few unused addresses somewhere between $7E00F0-$7E00FF (direct page!), and $7E0660-$7E06FF appears to be unused during the majority of the game ($7E04A0-$7E065F is the HDMA table used to draw the "zoom," keyhole, and message box effects).
HyperHacker
Posts: 676/5072
That won't do much good without some sort of official database. Best bet would be to mix it into an existing address list.

Also you can't just say "I might use 7E0000-7FFFFF someday so nobody use them" or whatever, that's not fair.
Smallhacker
Posts: 182/832
So... We'd better get them while there still are any left?

I claim 7EC7F0-7EC7FF, and probably 7EC7D0-7EC7EF too.
HyperHacker
Posts: 657/5072
That's one of the problems with ASM hacks. There's no real way to keep track of what uses what RAM address. (A list could help, but everyone would need to put their addresses in it, and they might not.)

However, most memory maps mark what appears to be free space. Those filled with 0x55 are never touched by the game.
Kailieann
Posts: 235/808
Yes, it is used by the locked door blocks. It's also used by LevelASM. Neither of which are part of the original game, and both of which can be modified to repoint to other RAM addresses easily enough.
jp
Posts: 25/52
About those unused spaces (all 55s), $7E010B is used by the blocktool locked blocks and keys. I had to move out of there when I realised the keys weren't working any more
Sukasa
Posts: 527/2068
Too cool. So, that's the speed of the walls moving inward? Radical. Now, which of those two values actually changes the speed, and what does the other one do, assuming that they are 2 8-bit numbers, or are they opcodes?

EDIT: What were they before you changed them?
MathOnNapkins
Posts: 132/1106
Well you could use GSD and play for quite a while to see if there are any writes/reads of the given location. Other than that it is quite difficult to say for certain that a given address is unused. You'd have to have a complete grasp of everything that the game can possibly do.
Kailieann
Posts: 234/808
Originally posted by MathOnNapkins
You're forgetting that the code is in a LoRom game, which only uses half the bank. The other half is RAM, and well... good luck trying to get RAM to stay consistent.


This could easily be valuable though. If one were to find five consecutive unused RAM addresses (or rearrange the existing code so that five consecutive RAM addresses became unused) you could write a JSL (+ address + RTS) to RAM and potentially use it to change a sprite's ASM code on the fly.

I actually went on a dead-RAM hunt a while back, and $010B-$01CD looked like they were completely unused, but my D-pad is still broken, which makes it extremely difficult to test these kinds of things. I only made it as far as Yoshi's Island 3, and there were a few offsets after $01CD that looked equally blank until I hit certain spots.

If anyone cares to continue my research, the other non-WRAM (seemingly) unused addresses I came up with were $918B, $918D, $918F, $C100-$C7FF, $7F0000-$7FFFFF, $7F8183-$7F837A, and $7F8396-$FC7FF
All you have to do is keep an eye on them and see if they change to any value other than x55, which is the default RAM value when the system is turned on.
HyperHacker
Posts: 628/5072
Haha, compared to some of the 9/11 theories I've heard, that actually sounds fairly plausible. 9 + 1 + 1 = 11 and George Bush was 9 years old once and one of his relatives is 62 and there's one 6 and one 2 in 62! OMG CONSPIRACY
asdf
Posts: 174/4077
Originally posted by HyperHacker
BTW, the odds are 1 in who cares?


This man, he speaks the truth. Hell, I could say that D364 is 54116 in decimal. That number has 411 in the middle, the number you dial to get information on the telephone. Smallhacker's brother provided information. Or I could say D364 is 151544 in Octal, or whatever the hell you call Base 8. There are two 1s, two 4s and two 5s. If we put 212425 into decimal and convert it to hex, we get 33DC9. DC. Washington DC. Smallhacker's brother is working with the governmen*gets shot*

Oh, and about the walls. This is a good...find. If there are no freezing or trapping glitches, this could make for an interesting boss battle. Which is a good thing, considering SMW's bosses are hard to make interesting unless you do something incredibly unusual. This fits right in.
HyperHacker
Posts: 625/5072
Have him try more, maybe he'll find something else.

BTW, the odds are 1 in who cares?
MathOnNapkins
Posts: 130/1106
You're forgetting that the code is in a LoRom game, which only uses half the bank. The other half is RAM, and well... good luck trying to get RAM to stay consistent.
jp
Posts: 23/52
Um... if possibilities range from 00 00 to FF FF wouldn't that be 1 in 65536?

BUT... this is not an equi-probability problem... Every 2-byte combination doesn't have the same probability of resulting in success. Actually, the CPU and ROM work as a (very complicated) function that returns that result.

Apophis
Posts: 178/734
So he found not only a working sprite, but also the shrink room routine, and you want to hurt him? Give him a fricking medal!
spel werdz rite
Posts: 568/1796
Calculation:
First, the highest hexadecimal number goes to is 256 (FF) which is 2^8
Because it has to be two numbers in a row, you would square the number (2^8)^2=2^16 (65,536)
Because it only goes from 0 to FFFF (because it has to be exactly two bytes and 00 xx counts) the decimal equivalent of that is 65,536 which means all possibilities range from 0 to 65,536.
Due to the order of probability, the next step would be (2^16)^65,536=2^1,048,576

And those are your odds: 1 in 2^1,048,576
As for finding out how many digits that is, when you take 2^n it will increase one more decimal every three or four times. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384
It increases in that pattern for a while, that basically boils down to 3.33 times to increase a digit. (it's not exact, but it's close)
So to find the number of digits, it would be 1048576/3.33=314572.8 which rounds up to 314,573 digits.

To make this post a little on topic, I'm going to try different values around xD364 to see what elese happens with the walls.
jp
Posts: 22/52
Hehe... I wonder what calculation you guys made for the odds... Because conditions for success are incredibly complex, overwriting a byte at random in an assembled program could be changing anything from opcodes to pointers or processor flags, or a loop, or a routine that is executed every frame!

It's a dynamic system with thousands of variables, a calculation would have to take the whole system into consideration! That is, you would have to execute all the code up to that address, for every one of them! (absolutely impractical)

And I'm curious about how you defined success (that is, "something useful") in your probability calculation?
richyawyingtmv
Posts: 61/294
Originally posted by Smallhacker
I named a SMW ROM "D364.smc", jumped to 0xD364 in a hex editor and entered D3 64. Then I tested the ROM. I became even more annoyed at my bro.


Just wait until your brother wins the nobel peace prize for that find
S.N.N.
Posts: 229/2028
That seems really cool. I nominate D364 for the hex address of the year

It looks like Mario and Roy/Morton get pushed OUTSIDE of the walls. Would it be possible to make the walls stop at a certain point, and instead of making the characters act crazy, actually kill Mario? That could be used to make a tough boss battle if it worked.

Smallhacker's borhter is the new god around here
This is a long thread. Click here to view it.
Acmlm's Board - I3 Archive - ROM Hacking - Mess up Morton and Roy's walls (SMW)


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.003 seconds; used 368.48 kB (max 434.88 kB)