SunGodPortal's Burning Questions

1) Okay. I'll live.

2) The first 2 sentences make me wonder if you misunderstood me. It's not the actual graphics I want to edit in this situation. I'm just wondering if there is a way to, for example: add the sanctuary (from set #41) to what the overworld editor refers to as GFX set #35 so I can use it in town without it looking vomited.

It's not the actual graphics I want to edit in this situation. I'm just wondering if there is a way to, for example: add the sanctuary (from set #41) to what the overworld editor refers to as GFX set #35 so I can use it in town without it looking vomited.

That's not going either (or at least partially if you renounce on some tiles).

Here the gfx sets (standard sets= compatible to all gfx values):



Entire village is using 3 sets (so full, nothing more can be added, unless you could bring the church into these 3 sets, but there is no room).



Church gfx set is separate here and also has some graveyard tiles.


This is how the game works: you are limited to 3 unique sets per one gfx-set number. You are basically loading a specific set from the global gfx (all sets) onto the same "place" (depending on the number). So number #41 means load 3 unique sets ("house", "church" and "graveyard), #35 means load: house, village tiles1, village tiles2.

There is basically no way to load 5 unique ones (while still having trees and hills and bushes), which you would need to bring the church into the village. There would also be palette problems.

But you can load the house tiles in the church area (since the house gfx is loaded by default with #41), and the pal is compatible.

This basically means you need to thoughtfully choose your style of area and fit all (nonrepeated smallest) tiles into 3 unique gfx sets. And place them so, that the tile properties match (for instance 0 is walkable, type 1 is solid etc). One type is defined at one "location", no matter what gfx set is "loaded into it", which makes it very difficult to do.

I know this is a strange tactic, but that's how the game sees it.

Okay. Thanks. I have a much better understanding of this now. I should have been able to figure this out on my own but every time I read up on this stuff in the Z3 Compendium I kept feeling like something was missing or that the specific details I wanted were in another section or something.

Anyway, if the "Perfect Guide to Hyrule Magic" is correct there are a bunch of duplicates of the village GFX set, so hopefully that will give me a little more breathing room. Since I'd like to have a much larger village I need all of the variation I can afford.

Can anyone identify the tile I've high-lighted here? It looks like a book or something but I've already gotten rid of the library sign, so that's not it. I searched the entire overworld and didn't see anything that looked like it.

The above image is something I'm making in MS Paint just for my own reference. I'm going through the village GFX set and seeing what tiles I might like to replace.

EDIT: Okay I finally figured it out. It was the stone with the ancient writing, in front of the desert palace.

Change the palette to "2bpp" and go almost all the way down, and find the smaller numbers. They should be there.

I've edited the numbers in 2BPP mode where they are split up into two layers. I've edited the numbers in 4BPP mode where they actually look right. I've copy/pasted other numbers from the game into their spots. I've tried redrawing them from scratch as well. They save just fine in my GFX.bin but after I recompress them, I go to play the game the original numbers remain, despite the fact that I replaced them. This doesn't make any sense to me. I'm not sure what I'm doing wrong. It's almost as if they refuse to reinsert.

SunGodPortal wrote:I've edited the numbers in 2BPP mode where they are split up into two layers. I've edited the numbers in 4BPP mode where they actually look right. I've copy/pasted other numbers from the game into their spots. I've tried redrawing them from scratch as well. They save just fine in my GFX.bin but after I recompress them, I go to play the game the original numbers remain, despite the fact that I replaced them. This doesn't make any sense to me. I'm not sure what I'm doing wrong. It's almost as if they refuse to reinsert.

The only way this is possible, if you are using save states or old srm saves. The text is problematic when it comes to correctly "reloading the game". Once you recompress the gfx (numbers or text), you need to load the file and start a new game.

Puzz wrote:The only way this is possible, if you are using save states or old srm saves. The text is problematic when it comes to correctly "reloading the game". Once you recompress the gfx (numbers or text), you need to load the file and start a new game.

I remembered somebody else having that problem so I made sure not to use any save states. I even deleted the .srm saves just to be safe. Nothing. All of my other changes work but I can't get those damned number graphics for the arrows/bomb/rupees to change. I even deleted and re-downloaded zcompress just to make sure it hadn't become corrupted or something. Nothing. I made a new dump of the gfx. Nothing.

The only other thing I can think to do is have zcompress dump the graphics into chunks like it does if you don't add "allgfx.bin" onto the end, edit the chunk with the numbers and then reinsert only that. The only problem there is that it asks where you want the gfx inserted. I would have absolutely no idea where they would be inserted to because the only graphics locations I've read were in YY-CHR and they obviously don't match up since you typically want to reinsert them at 87200, according to zcompress. If I tried to look that location up in YY-CHR it would be WAY past where I need anything. I really don't want to do it this way though since I'm pretty sure Dogeritos didn't have to go through this much BS just to change the exact same graphics. It's a mystery for sure...

No clue what's happening here, since I also edited those numbers without problems. Furthermore: you need to choose the address 87200 (and the file must have the header, so this is actually at 87000) for the gfx to work properly. Choosing a different location will cause bugs and other problems.

The address 87200 applies to the rom address, not gfx address. So this location is set and can not change. So you recompress with this command:
zcompress 1 87200 zelda.smc AllGFX.bin

(the names of smc and bin files are only examples)

One possibility is, that you ran out of gfx space (which however usually doesn't happen unless you really fill-in lots of new empty spaces).

Another possibility would be to Not use the latest version of zcompress, but rather the old one (which I'm using), since the new one is in Japanese and displays false letters (only fixable if your language code is compatible and on the list of the program).

I'm just gonna give up on it for now. It's starting to piss me off, having to spend this much time on something so trivial. I've tried every solution within reason and even few beyond it. HOURS have been wasted on this when I could have used that time for overworld editing... That's what I was actually working on before I decided to take a quick break from that to do something that by all accounts should have been simple and easy. All I wanted to do was replace the numbers from the display at the top with what I believe are the numbers from the save menu after you beat the game. I just wanted to see what it would look like.

"GRUMBLE, GRUMBLE..."

I'm looking for something that I thought was on this site.

At some point while I was looking around here or somewhere else I noticed in someone's post there was something like "kill annoying message" or something similar and I believe it was refering to the telepathic message Zelda sends you when you're on the way to rescue her. This information followed:

$07/F498 - change from SEC to CLC (0x18)

I didn't pay a lot of attention to it but I thought "That might come in handy some day" so I copy/pasted it into a doc on my computer where I collect random codes relating to ALttP.

Now that I actually do need a code to disable that telepathic message i was trying to figure out where I found that stuff because I need more information. When I refered to my notes I was expecting to find some hex, but what the heck does it mean by SEC and CLC? Is that some kind of ASM stuff?

Can anybody help me here? I've searched Zeldix and RHDN but haven't found what I'm looking for.

As many of you are aware, I've hijacked Bruce Campbell vs Ganon. One of the first things I want to do is disable the "dildo" message. I'm not interested in changing the contents of the telepathic message, I just don't want a message to appear in that scenario. It's completely unnecessary.

It means, what it says, but written in the "ASM language". This was definitely written by the "coder", who knows his ASM.

SEC is Set carry flag command, which coresponds to byte value 38 in hex, and the CLC refers to Clear carry, which coresponds to byte value 18 (as stated by the 0x18 in the bracket). While the $07/F498  is the SNES address. This is pretty much how the Geiger's SNES tracer would output the data.

It basically means (in "normal" language) to go to pc or hex address 3F498 (which is 7F498 SNES) and change the byte 38 (set carry flag or SEC) to 18 (clear carry). If you think about it the "clear carry" will disable the command. It is basically a "smart" way to NOP (no operation) the command, rather than to use an EA hex value somewhere else.

I tested this out and it works, if you change 38 to 18 at 3F498, the intro message "Help me I'm in a dungeon..." which pops up multiple times untill you reach the uncle, will not appear.

Here the list of all the Opcodes and their hex values if you are interested:
http://dl.dropbox.com/s/p1p52np5t6igur2/ASM-to-HEX-Opcodes.docx?dl=0

Puzzledude wrote:I tested this out and it works, if you change 38 to 18 at 3F498, the intro message "Help me I'm in a dungeon..." which pops up multiple times untill you reach the uncle, will not appear.

Cool. Thanks for testing it and for the explanation. I'm sure anyone who plays the new version of BCvsG should appreciate this. haha Now if I could just figure out where I got that. If it didn't come from somebody we know then there might be a future friend out there who really needs to join Zeldix.

Puzzledude wrote:Here the list of all the Opcodes and their hex values if you are interested:

Oh wow. That'll come in handy some day. (no, I'm not being sarcastic) I love doing stuff in hex but feel that I'm not quite ready to tackle assembly head-on. When the time comes this will make bridging the gap a little easier.

To explain the carry flag, it is part of pseudomath the cpu does....
If you substract 07-08 you get FF, so you Need to know whether you got below Zero, the cpu clears the carry flag (it serves as an additional bit). Therefore, before every substraction you Need to set carry (SEC=38) which is cleared when getting below Zero with your substact math.

Opposite is in Addition. If you e.g., add FE+03 you get 01 so the cpu sets the carry because you get above zero, therefore, before every Addition you Need to clear the carry (CLC=18).


Example, look into the flag Register P:envMXdiZc:

$09/C615 38          SEC                     A:0C00 X:00FE Y:0001  P:envMXdiZc
The Carry Flag is not set, when executing the SEt Carry

$09/C616 E9 30       SBC #$30           A:0C00 X:00FE Y:0001 P:envMXdiZC
Here, in the next line it is set due to SEC, we substract 30 from 00 in A: (8 bit set)

$09/C618 85 0E       STA $0E             A:0CD0 X:00FE Y:0001 P:eNvMXdizc
Now it is cleared since 00-30=D0 (look in the 8-bit Accumulator) and flag register


One note to 8 bit 16 bit mode. The accumulator A:xx yy has 2 Bytes (word) if you set the M-memory flag P:eNvMXdizc, the read is 8 bit, means it only takes the yy Byte. If the Memory flag is cleared (m) both Bytes (xx yy) are taken for calculations.

You have more flags. Important is also the X flag which sets the X and Y Registers to 8/16 bit while the M can still be Independent in 8/16 bit mode.
The N is the negative flag (00-7f is positive, 80-ff is negative), z the Zero flag (e.g. boolean true/false operations). Look in above example Registers, the Z is set when the A: is 00. The N flag is set after the calculation since the result D0 is in the negative range). The other flags are hardly needed for asm coding

$09/C615 38          SEC                     A:0C00 X:00FE Y:0001 D:0000 DB:09 S:01EB P:envMXdiZc
The Carry Flag is not set, when executing the SEt Carry

$09/C616 E9 30       SBC #$30           A:0C00 X:00FE Y:0001 D:0000 DB:09 S:01EB P:envMXdiZC
Here, in the next line it is set due to SEC, we substract 30 from 00 in A: (8 bit set)

$09/C618 85 0E       STA $0E             A:0CD0 X:00FE Y:0001 D:0000 DB:09 S:01EB P:eNvMXdizc
Now it is cleared since 00-30=D0 (look in the 8-bit Accumulator) and flag register

Haha

I'm not ready. Thanks for the effort though.

SunGodPortal wrote:

$09/C615 38          SEC                     A:0C00 X:00FE Y:0001 D:0000 DB:09 S:01EB P:envMXdiZc
The Carry Flag is not set, when executing the SEt Carry

$09/C616 E9 30       SBC #$30           A:0C00 X:00FE Y:0001 D:0000 DB:09 S:01EB P:envMXdiZC
Here, in the next line it is set due to SEC, we substract 30 from 00 in A: (8 bit set)

$09/C618 85 0E       STA $0E             A:0CD0 X:00FE Y:0001 D:0000 DB:09 S:01EB P:eNvMXdizc
Now it is cleared since 00-30=D0 (look in the 8-bit Accumulator) and flag register

Haha

I'm not ready. Thanks for the effort though.

Maybe it would be easier if you don't look at the registers and the accumulator yet and focus on the left side only. At 09C615-snes or 04C615-hex there is a code in original Alttp:

Code:

38 E9 30 85 0E

This is actually assembled ASM,

which if disassembled would be:

Code:

SEC        (executed at $09/C615)
SBC #$30   (executed at $09/C616), 1 byte after
STA $0E    (executed at $09/C618), 2 bytes after


     
38 is SEC, E9 is SBC (30 is the value), 85 is STA (0E is the value), # is value, $ means the value is in hex (and not dec) system.

From my point of view ASM is complex and out of reach for me to actually come up with some brand new code. But I can understand once it is written by someone else.

Since you guys are making an effort here I'll go ahead and try to begin learning this stuff now. I am interested in learning ASM but I keep wondering if there's something else I should learn first. When it comes to programming I am an absolute beginner so sometimes I feel like I'm trying to understand something without the benefit of a context. That may not always be the case, but that what it feels like.

I fooled around with QBasic when I was a kid (in the early 90's) but that feels like 100 years ago and I remember next to nothing about it. Plus, I don't need to tell you that QBasic and SNES assembly are two very different things. I never learned to write programs but I did figure out how to make a number of small changes to the QBasic Gorillas game that was on the outdated computer that was given to me. I can't tell you how cool that made me feel being around 10 years old. My older brother and sister's friends thought I was some kind of genius. LOL I was just bored and learning things from trial and error.

Even if I did remember any of that stuff I don't know how much help it would be. So I'd like to make it very clear that I don't know the first thing about programming of ANY type. It's a foreign language to me, but one that I am interested in learning AND using.

Maybe I'm just over-thinking things but something tells me that I'll have a much easier time with ASM if I just learn something simpler first, that way more of it will make sense to me. It's really annoying trying to learn something and having to stop 2 or 3 times in every sentence to look up what this term or that term means only to find that I again have to look things up just to get a better understand of what I was trying to look up in the first place.

I know I'm capable of this, I just need a better foundation for my knowledge/studies.

Hyrule Magic...

So I'm rebuilding BCvsG into a new ROM (meaning I'm starting with a fresh ROM). First, I expanded the ROM to 2MB and used the Move Pointers > Move Headers option to relocate that data to 120000. Then I went through a number of rooms that for the time being are of no importance (rooms 47, 254, 257, 258, 259-12*, 262, 263-12*, 264, 268, 274, 276, 277, 283, 290, 291, 293, 294, 295) and cleared out a bunch of stuff to give me some space to work. I finished room 3 and 260. After finishing these two rooms, for some reason when I move on to my next target (room 85) that room is cleared of everything but sprites, items and a torch. Even the exit door is gone. No other rooms seem damaged.

I've been making backups obsessively so I know for a fact that room 85 is just fine before I build rooms 3 and 260 but afterwords it is always empty. Do any of you who are more experienced with HM know why this keeps happening? I could go ahead and try to rebuild that room from this state but if this is going to continue to happen I would like to know why (if possible) so I can devise a strategy to deal with it. Thanks.

*by "-12" I'm refering to the part of the room layout that is entered from the door in the "12" position, not the entire "room"

On a side note: Anyone know of a good tutorial on how to apply ASM patches? I'm getting tired of not knowing how to do this. I could really use XaserLE's "Hacker's Cheat" (it would really help during tests) but I don't know how to get that info into the ROM. I've done searches of the site and google but I'm not getting the results I'm looking for.

Judging from the above this is a false pointer calculation, which you need to fix manually, but... since you cleared so many rooms, your file might be affected already. You cleared rooms above 255. It is actually not wise to touch rooms above 255, specially 280-295 (tend to bug, even if you remove things). And it is not wise to add to much to your house (room 260).

Try to work in this area only to gain space: room 0 to room 255.

Rooms 260-295 tend to be fragile and overlap with the menu code, so for instance any edits to room 285 might make bugs with the Naming screen.

I know all this sounds discouraging, and the program is problematic, but currently this is how things are.

Since you guys are making an effort here I'll go ahead and try to begin learning this stuff now.

You can regard ASM as advanced editing. That's how I see it and I never mastered it. This definitely needs an intelect very much different from any other editing (gfx, dungeon, overworld, etc).

On a side note: Anyone know of a good tutorial on how to apply ASM patches?

That's easy. You don't really need a tutorial, just the program Xkas:
http://dl.dropbox.com/s/tkuwi1w4oac2bz5/Xkas-upload.zip?dl=0

Extract the zip, put your rom into the folder. Run CMD (inside already). Then type in (similar to zcompress):

xkas.exe The_name_of_the_patch.asm The_name_of_your_ROM.smc
Then hit enter.

for instance
xkas.exe asm.asm Alttp.smc

This will assemble the ASM into the hex code and put it into the rom (since the ASM also contains info on where to put the new code, and where to make the jump to it).
Since there is an asm.asm file already in the folder, you can test this and bring this asm into any file (which is the Flute ASM written by Conn to make the floor visible while playing the flute= same effect as you would light the torch and invisible floor appears, ie in room 156).

I know all this sounds discouraging, and the program is problematic, but currently this is how things are.

hehe I understand and just as I've said before, I'll live. I'll try to leave the rooms over 255 alone. That sucks about Link's house though. I suppose if I became familar enough with the data structure of the game I could have a better idea of just how much I can do with that room by keeping an eye on certain locations in a hex editor as changes are saved.

I'm just gonna start over. At least I didn't have to get very far into it before I had to learn this lesson. This way I can laugh about it instead of going out into the street and thrashing the first person I meet. LOL

You can regard ASM as advanced editing. That's how I see it and I never mastered it. This definitely needs an intelect very much different from any other editing (gfx, dungeon, overworld, etc).

I'd feel comfortable trying to lay some groundwork on this front but for now that's about it. As far as I can tell I won't be needing to craft much ASM for this hack, if any (fingers crossed) so it's not a top priority. I'm sure it would come in handy with Pinky's Quest but it looks like I'm doing the exact opposite of what I said I would: I seem to be focusing solely on making a Bruce Campbell vs Ganon - Redux rather than spending time on MY hack. I don't feel bad about it though, because I know the experience I gain doing this BCvsG thing will make PQ 1000 times better (ahhh, the glory LOL).

That's easy. You don't really need a tutorial, just the program Xkas...

Okay. Sounds simple enough, but what do I have to do if I only have the code, not an actual patch? For example, the one I'm wanting to use right now doesn't appear to have an IPS or anything for download.

EDIT: Oh wait. I can read the .asm in notepad. Does that mean I can just copy/paste the code I want into that?

Okay. Sounds simple enough, but what do I have to do if I only have the code, not an actual patch? For example, the one I'm wanting to use right now doesn't appear to have an IPS or anything for download.

EDIT: Oh wait. I can read the .asm in notepad. Does that mean I can just copy/paste the code I want into that?

ASM is usually not really called "patch", since the patch by default means IPS patch, ie the patch converts one file to another, by "changing" the code. While ASM is actually "adding" new code. So it is rather called a "file" or "code".

So if you have the ASM code alone (with no ASM file), you need to copy/paste it into a file with the .asm extension. You can also paste it into the standard .txt and change the extension to .asm. And then use Xkas with this file.

(In my case I just have an .asm file in the Xkas folder all the time, and copy paste various asm codes into it, while the file is always called asm, so I don't have to type in different names all the time into the CMD).

And in the "open with" dialog of your Operating system you might want to associate the asm file to the wordpad or notepad, so you can just open it with a doubleclick like a standard txt.

I've noticed that in HM's dungeon editor the existing Goriyas show up as Red and Green Rocklops' (Eyegores). Is there some trick to actually being able to use the Goriyas?

ASM is usually not really called "patch", since the patch by default means IPS patch, ie the patch converts one file to another, by "changing" the code. While ASM is actually "adding" new code. So it is rather called a "file" or "code".

I may be a little late in saying this, but thanks for explaining a few things regarding this subject. I have a lot more options now.

I've noticed that in HM's dungeon editor the existing Goriyas show up as Red and Green Rocklops' (Eyegores). Is there some trick to actually being able to use the Goriyas?

Not really (unless you use ASM). You are actually out of luck with HM when telling the game which of the enemies should be Rocklops and which Goriyas. This is so, because this is the same sprite. But the game still knows what to load, because of the room number. So it knows to load the Goriyas if you are in a certain room, but the Rocklops are the default for this sprite.

Similar system for the red/blue type of the same enemy, such as the Stalfos (could be regular or with the red head, and the later are different, since they throw bones). I never actually studied how the game chooses them, since the sprite is the same and it is not room dependent.

https://www.zeldix.net/t446-changing-the-rocklops-into-mimics

Conn found this sometime ago.

Yes, I remember this. But I think you are still limited to 4 rooms only for the Mimics/Goriyas? So the Rocklops sprite will still display the Rocklops in the majority (unless you can somehow expand the number of those 4 rooms).