Banner
Views: 993,201,271
Time:
14 users online: Aja,  Anorakun, bersi,  BTD6_maker, E-man38, Eduard, gui, Natsu, Neidave, Neuromancer, TheOrangeToad, TRLuigi, Uivandal, VLSkoot - Guests: 77 - Bots: 198 Users: 54,464 (2,082 active)
Latest: TRLuigi66
Tip: If you give a Muncher tile custom graphics, it will still act like a coin when a silver P-switch is active, whether it looks like a coin or not. ExAnimation solves this problem.
Not logged in.
New ROM address submission rules
Forum Index - Important - Announcements - New ROM address submission rules
Pages: « 1 » Link
(Revision 1)
Recently I became a ROM map moderator (as some of you might have noticed). Me, FuzzyFreak and Alcaro went through the ROM addresses today.

It all started with the recently submitted ROM addresses (16 of them, which 3 of them actually passed).

The submitted ROM addresses were all like

"Unknown/Strange byte. Changing this to any value will give strange effects to whatever in the game. Changing it to 00 crashes the game"

Or

"Something, original value is 8D. Changing this to whatever gives you strange results. Changing it to FF or EE will give you neat results. xx value will crash the game"

After moderating the ROM addresses we went through the ROM map. It was filled with crap. Some addresses were faulty, incorrect location, linking to a fatal crash byte, or whatever disaster there are in the ROM. Though, most of the submitted ROM map addresses pointed to ASSEMBLY OPCODES!

Modification of ANY Assembly code ALWAYS has a risk of breaking something in your ROM. Yes, I also mean xkas patches. ...putting xkas aside, my point is the "Strange Bytes". Most of those strange bytes addresses point to assembly opcodes. Almost nobody knows this: changing an opcode to 00, 02, 42 or DB, will CERTAINLY crash the game. That is why we do NOT allow such bytes anymore. Consider this as rule 1 of ROM address submission rules.

Rule 2
THIS RULE APPLIES TO BOTH ROM MAP MODERATORS AND ROM ADDRESSES SUBMITTERS, YES, INCLUDING MYSELF.

The most common mistakes people do is, they do NOT double check if the address is correct. I've saw numerous of INCORRECT ROM ADDRESSES in the ROM map. Of course I removed them. Why does this apply to moderators too?
How did they pass the moderation?! ALWAYS CHECK IF THE ADDRESS IS CORRECT. ALWAYS ALWAYS ALWAYS!

Rule 3
The ROM addresses may NOT contain any bugs/side effects, UNLESS THERE IS A FIX FOR IT.

Someone told me about the "Change 5 bytes to EA EA EA EA EA to disable gaining 1-up at the goal tape while carrying an item", and according to him, he carried a key to the goal tape. The key did not change at all, and just blocked the player from doing the 'ending march'. Such cases are considered as side effects, and such addresses will be REJECTED!

Rule 4
I'm surprised I never saw this anywhere...
ROM ADDRESS MUST BE COUNTED WITH ROM HEADER
Why?
Well, if you want to freeze your ROM for some reason, you want to change the very first opcode SEI, to STP (meaning of STP explained later). If the address was submitted at 0x0000, you would change the header of the ROM instead of the start of the ROM. If you include the header you get 0x200, which is SEI. You change it to DB. You get STP. You hex edited the ROM successfully. In case you don't know, a header has a bunch of 00s in it.
"Why header and not a non-headered ROM?"
Lunar Magic only supports headered ROMs... And it makes the work a lot of easier, instead of adding and removing the header all the time, or grabbing Lunar Address all the time to calculate the correct ROM address.

As an addition to rule 1...
People should NOT be submitting opcodes, UNLESS YOU KNOW THE PURPOSES OF IT. It would be just annoying if people changed random ROM addresses to DB. DB means STP in ASM, which means "SToP the clock". In other words, you freeze the whole game. You can submit a ROM address linking to a branching opcode, such as:

Change BEQ to BRA to get whatever effect.
Wording it in hex:
Change F0 to 80 to get whatever effect.

Additionally, you can NOP out existing code. NOP = EA. They absolutely do nothing besides wasting time. Though, when you NOP out stuff, do it PROPERLY. Example:

LDY #$02
LDA #$03
STA $DB,x
RTS

In hex:
A0 02 A9 03 95 DB 60

You want to NOP out LDA #$03. In assembly it would be simple. In hex, however not. Faulty NOP:

A0 02 EA EA EA DB 60

LDA #$03 is 2 bytes. You NOPed out 3 Bytes. The game would read this as:

LDY #$02
NOP #3 ;3 times NOP
STP
RTS

STP is already fatal, so you screwed up.
ALWAYS NOP out the correct amount of bytes. A correct NOP-out:

A0 02 EA EA 95 DB 60



To get a whole list of opcodes and their hexadecimal versions, download this file

To get the whole SMW disassembly, download "SMW's Disassembly (all.log)" from the documents section. It basically has all the ROM addresses in there, though, almost 90% of it is undocumented. You can see in that file, if you got an opcode as an address, or a value. Note that everything is in PC SNES instead of PC HEX. Use Lunar Address to convert between those 2 formats.

To be honest, I was quite pissed off today due to these ROM addresses stuff. Please avoid breaking these new set-up rules. Have a nice day, and sorry for the wall of text. Someone had to do it. I do know that the ROM map is mostly for documentation purposes. You don't have to submit edit-able addresses all the time. Just... make sure they are all correct.

tl;dr double check ROM addresses before submitting them, and don't give them strange descriptions.
Thanks Ersanio. I've been reluctant to use ROM hacks because of the unreliability of most (or some, a lot I used were faulty) addresses.
Oh, thanks for this rule, Ersanio. I hope that most of the Rom Map entries work now... I tried editing something in SMW with Transhlexion once, and it crashed. D:
By the way, if any of you guys find a faulty ROM address (broken, side effect, incorrect, whatever), please let me know so I can check it out, and perhaps fix/remove them.
Another handy page for ASM <-> HEX conversion.

Also, it's good you set this rule up. It was getting really... really ridiculous.

--------------------
--------> Don't follow "Find Roy's Dignity", my hack. Because it's pretty outdated. <--------
Thank god. I've been getting pissed with the ROM map lately. All these extra things do are take up space, and more stuff for me to look through.
Yay for cleanup! :D

--------------------
<TLMB> I use YY-CHR to edit DNA
I disagree with Rule 3. Instead I would say that you just have to write down the side effects. Because for ASM hackers it is essential to know which addresses deal with what.
Originally posted by Deflaktor
Because for ASM hackers it is essential to know which addresses deal with what.

You can just fire up all.log and find all the addresses which deals with whatever.
It contains all the addresses anyway, the bad side is, it isn't documented too much.
I would like to remind people that BOTH the ROM and RAM map is only for a CLEAN SMW ROM.

We do NOT accept RAM addresses like:
"Used by someone's whateverpatch"

Or ROM addresses like:
"Blocktool's subroutine"

--------------------
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Originally posted by Morton
I would like to remind people that BOTH the ROM and RAM map is only for a CLEAN SMW ROM.

Originally posted by ROM and RAM maps
001FF N/A 1 byte Misc. it equals 01 if the hack is locked.
081BF $00:FFBF 1 byte Misc. Is 42 if the hack is locked
30657 $06:8457 1 byte Music Change from 9C to 8D to fix the P-switch music repeating glitch when using...
$7E:BD00 7 bytes Misc. Used by custom block ASM/XAnimated Tile GFX
$7E:C380 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate Mario's direction (1-up, 2-right, 3-down...
$7E:C381 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the counter that increments when Mario is...
$7E:C382 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the counter that increments when Mario is...
$7E:C383 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the Mario/Yoshi status (1-small, 2-big...
$7E:C384 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the target location of corner piece low byte
$7E:C385 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the target location of corner piece high byte
$7E:C386 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the water level flag
$7E:C387 1 byte Blocks Used by Mikeyk's SMB3 Pipes to indicate the time that Mario has entered the pipe
$7F:0B44 2,048 bytes Sprites GFX for currently loaded dynamic sprites: The sprites load their GFX in here...
$7F:8601 1 byte Player Used by Schwa's Pseudo Powerups to determine what powerups Mario has, in Binary...
$7F:8602 1 byte Player Used by Schwa's Pseudo Powerups to determine if Mario has already used his...
$7F:8820 Unknown Sprites Used by Mikeyk's Ice Power generator
$7F:8821 Unknown Misc. Used by Mikeyk's mushroom block (sprite portion).
$7F:8900 768 bytes Sprites Extra sprite tables used by smwedit's fire chomp, and some by smwedit's chain...
$7F:AB10 12 bytes Sprites Used by Sprite Tool...
$7F:AB1C 1 byte Sprites Used by Sprite Tool to indicate whether the sprite being processed uses custom code
$7F:AB28 12 bytes Sprites Used by Sprite Tool to indicate the extra property byte 1 from the cfg file
$7F:AB34 12 bytes Sprites Used by Sprite Tool to indicate the extra property byte 2 from the cfg file
$7F:AB9E 12 bytes Sprites Used by Sprite Tool to indicate the custom sprite number
$7F:FF00 32 bytes Misc. Used for LevelNames 2.0 by Ice Man
$7F:FFDF 10 bytes Misc. Used by BMF's LevelNames code
$7F:FFF0 10 bytes Blocks Used by FuSoYa's SMB3 Pipe Code.
$7F:FFF0 4 bytes Misc. Used by BMF's LevelASM code
$7F:FFF8 8 bytes Misc. Used by LM demo recording/playing ASM

This makes no sense...

--------------------
<blm> zsnes users are the flatearthers of emulation
Those were there like since I joined SMWC (well, most of them).

I still think if I shall remove them or not. I better discuss with a staff member or something.

--------------------
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Why not keep them? If they would be removed from the RAM Map, someone who uses Sprite Tool might think $7FAB10 is free space, and if he used that for custom ASM stuff, it would screw up, and he wouldn't know where the issue came from.

--------------------


 
Originally posted by WhiteYoshiEgg
Why not keep them? If they would be removed from the RAM Map, someone who uses Sprite Tool might think $7FAB10 is free space, and if he used that for custom ASM stuff, it would screw up, and he wouldn't know where the issue came from.


I just don't think they really belong in the RAM map... besides, there's a text folder that comes with sprite_tool which explains the tables and where they're located. OR there could be a seperate section on SMWC for this, but for such a small thing, I don't see this happening.

--------------------
--------> Don't follow "Find Roy's Dignity", my hack. Because it's pretty outdated. <--------
Nuked the RAM addresses. Not sure about ROM addresses...

--------------------
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
HyperHacker
I do think there should be another table of addresses used by hacks. Or just have a flag for it, with the option to hide those.
My projects - ROM hacks, Gameshark codes, homebrew, useful apps, online 65816 disassembler
SCAM: HomebreWare and Wiiunlocker
Generation over 9000: The first time you see this, put a meme in your signature.
Pages: « 1 » Link
Forum Index - Important - Announcements - New ROM address submission rules

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2022 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks