[B.B.Link]

I started to make a Master Quest-like hack of LTTP using the only editor out there for it, Hyrule Magic. So I was editing Hyrule castle and went to the name select and it looked like this:



Does anyone who hacks this game know about this? My last backup has this bug, too. I know Hyrule Magic is a buggy tool. My rom size is 1026 bytes.

I also want to note that I can't extract the GFX with zcompress anymore or add/remove the header with Tush. Am I doomed with this.
August 21, 2013, 10:08:07 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Anybody? Puzzledude?

[puzzledude]

I didn't see this topic, then I would answer quicker.

Your main problem is the filesize! You need a hex editor! Like freeware HxD hex editor to fix your problem.

here it is
http://acmlm.kafuka.org/uploader/get.php?id=4306

Open the rom in the hex editor, and remove the first 200 bytes in hex or 512 in dec at the beginning (remove the header). Those bytes should mostly have the value 00. If your rom hasn't got those 00 bytes, it has no header already. Then go to the end of the rom and add (edit-insert bytes) 100000 bytes in hex (with the value 00).

Now go to address 200000 in hex. Select everything above this number and delete the bytes. You file will now have exactly 1FFFFF bytes in hex and will have no header. All your screens will now be ok (HM actually needs to move the data to the end of rom, and does this correctly, but the emu will not support a custom file size, such as 1.026 KB).

The complex "partial" pointers for all screens are here: 137D in hex and bank is 19 in hex long. If the last 7 bytes of this string are 20 (global bank definition to 100000), then HM has moved all screens to the end of the rom (good thing actually).
--------------------------


Regarding the zcompress. You must do the same thing as above. The file must have exactly 1FFFFF in hex. But zcompress requires a header (which is dumb); but all Fusoyas tools need a header).

So go to address 0 and add (edit-insert bytes) 200 in hex (value 00). Files size is now 2001FF and the file has the header. This is necessary for the file to be compatible to zcompress.


Funny part: after more editing, HM will auto shrink the file again (you must repeat the process in this case; or select around 200 bytes in hex at the very end of the file and choose fill-selection with FF bytes or 55 bytes; which could prevent HM from shrinking the file again; but with some operations HM will shrink it regardless).

Tush should react also if the filesize is 1FFFFF or with header 2001FF.

PS
You are never doomed, if you have the hex editor. Unfortunatelly we currently don't have any bug-free editors for this game, which forses us to look at the code directly in hex and debug all the bugs which HM makes. Also, a lot of things can be edited only in hex.

[B.B.Link]

Thanks, It worked! I thought I'd have to give up on this.

One more question. Do you know how to edit the title screen colors? I looked in that Perfect guide tutorial but didn't see the Red "Zelda" title pallete. I want to change it blue. Any Ideas?

[puzzledude]

"Zelda" title of the title screen

Go to Palettes, Area colours 1, PAL 3

Middle line are colours of the pal-3 in the title screen pal selection; you have 7 squares.

1st square - inner small portions of "Zelda" title
2nd square - black outer line of the letters
3rd square - inner small dots of "Zelda" title
4th square - left line of the letters (almost white)
5th square - /
6th square - right line of the letters
7th square - main inner colour of "Zelda" title and the most outer line of letters



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


Title screen background pal


Go to Palettes, World colours 1, PAL 5

First (upper) line are colours of pal-2 in the title screen pal selection, second line is pal-3, third line is pal-4, fourth line is pal-5, fifth line is pal-6.

All colours correspond to the gfx tiles connected with background of the title screen.

[B.B.Link]

OK so it worked 



But now 



Looks like my Hookshot, Bow and Rupees are glitched now....

[puzzledude]

Assuming that the in-game items are ok in the actual gfx and still having that bug; this is a DMA transfer issue.


SePH had this bug for 4 years and we recently debugged it.

I examined the gfx area. 87000-D0000. Corruption appears. So the code is here! This was good news! since the gfx does not corrupt the rom from being loaded! So the process is easy now (can take any amount from 87000-D0000) and still am able to load the srm, since I can not use save states.

Reduced this down by half, half etc to find the code between 8A400 and 8A500. Then down to one line.
--------------------------------------------

line is 8A480 (isolated, no other line corrupts), no header

wrong code is
32 72 32 72 16 32 36 32 12 1E 18 0E 08 00 00 0A
(or any random sequence)

correct Alttp code is!
A8 57 48 B7 B6 49 49 86 86 00 00 00 FF 00 FF 00

--------------------------------------------
Then we examine each byte and...

the primary part of the code is
A8 57 48 xx xx xx xx xx 00 00 00 FF

It seems like A8 loads (transfers) the correct gfx, while the ending 00 00 00 FF is necessary to correctly end the code. You can change those 7 bytes only, but it is better to go with all 13,
A8 57 48 B7 B6 49 49 86 86 00 00 00 FF.

As you can see the wrong code has no FF ending, resulting in a bug. The problem is that this is a part of global gfx code. So any gfx edit might destroy this again! Let us hope that the zcompress is smart enough not to destroy this.

Otherwise a hex fix is necessary after each change (recompression) of the gfx.

Note: This bug is usually a result of title screen edits, so the debug might have an effect on it. You can fix this by having the original Alttp code and new gfx in, while transfering the new title screen in the game via hex.

[B.B.Link]

Its hard to explain it, but I fixed it. By putting back certain parts of title screen I edited, I fixed the issue. Thanks again.