[SM] PLM data & scrol PLM data relocation

[BigDomino]

Hi guys,

Still working on my hack, I'm now trying to find the best options to manage bank $8F, as long as free space in this bank will be insufficient for what I plan to do in my game.

In Smile pointer pop-up and Smile Scroll editor, I found clickable "boxes" telling that PLM data and scroll PLM instruction can be relocated in another bank by just changing a couple of pointers :

$01:6B6E (pc) & $02:04AC (pc)  for PLM bank. [8F -> ??]
$02:0B60 (pc)  for Scroll PLM data. [8F -> ??]

Looking for info about that on the forum, I came across a patch made by PJBoy allowing the user to specify a new bank (without any restriction) for PLM and Scroll PLM data.

... if a patch was made for this purpose, does it means that the simple hex tweak suggested by Smile is not working properly... ?

Despite of this question I tried to apply PJBoy patch in both the .asm and .ips version but without success  :sad:.

For those willing to help me, I give here a description of what I have done and the result I got.
Maybe someone could highlight my mistake ?

A) Trying to patch with the .asm patch :

A.1) In xkas v.14 main directory (which contain xkas.exe)  I put a copy of my hack renamed : testpatchpjboy.smc

A.2) Then, in the same folder, I put a copy of the asm patch (PJManCustomPLMbank.asm) renamed :
testpatchpjboy.asm and opened it with Wordpad.exe

A.3) In the two "define" fields (at the beginning), I changed the original bank ($8F) to the new one where I plan to relocate PLM and Scroll PLM data (bank $E2) - and saved.

A.4) In the same directory, I created a batch file (starting from a .txt file then renamed .bat) which contain the following instruction :

xkas.exe testpatchpjboy.asm testpatchpjboy.smc
@pause

and executed it.

A.5) Via bankbuddy.exe, I finally duplicated the whole bank 8F in the empty bank E2.

A.6) I came back to Smile and opened the patched Rom.

A.7) The PLM bank specified in pointer pop-up was still 8F (no change)
        After testing, the game still read PLM data from bank 8F...

A.8) The bank specified in Scroll editor is still 8F (no change)
        After testing, the game still read scroll PLM instructions from bank 8F...

Question :
- Does it means that patching process has failed ? ...or, at that point, should I have changed by myself  the 3 pointers
  (at $01:6B6E  ;  $02:04AC ; $02:0B60 ) in a hex editor ?

A.9) I changed the 3 pointers aforementioned via hex editor.

A.10) I came back to Smile and opened the patched Rom (rom is still openable in Smile and PLMs are displayed properly).

A.11) The PLM bank specified in pointer pop-up is now E2.

A.12) The bank specified in Scroll editor is now E2.

A.13) But when I tried to Quickmet in rooms or another (containing or not PLMs), I got a black screen !

A.14) I tried to play the rom in an emulator - the game seems to load correctly - but i got a black screen in the second room of the game (i.e.: just after Ceres elevator shaft).

Finally, I tried to do the same process via xkas v.06 but in vain :
This version don't understand the syntaxes used in the .asm file (invalid opcode or command). 


B) Trying to patch with the .ips patch :

B.1) With lunarips.exe, I applied the patch on a new copy of my hack.

B.2) Then, following PJBoy instructions written in patch description (on metconst), I opened the patched rom in HxD and changed the bank (-> 8F to E2) specified at the following offsets : $01:68CA  ;  $01:6B79  ;  $01:6B7D (and noticed by the way that these pointers are not the same than those given by smile).

B.3) Via bankbuddy.exe, I finally duplicated the whole bank 8F in the empty bank E2.

B.4) I came back in smile and, in pointer pop-up, the bank for PLM data was changed for... A8 ?!  :pwuh:

B.5) In scroll editor, bank is still 8F.

B.6) After testing via emulator, the game freezes after Ceres explosion cutscene (just before landing on Zebes).

B.7) Quickmet is still working in the few rooms I tested but PLMs are now random data picked in bank A8... and obviously don't work properly.

In conclusion :  I'm pretty sure I've made a mistake somewhere... and I hope someone can help me.

In addition, may I ask if someone has already listed all or parts of the data which are not PLM related in bank 8F ?
I think these other data (including original scroll PLM data) should be erased in the duplicated bank in order to make free space for more PLMs and new scroll PLM data... (I mean, for hackers who want to preserve original PLM - Those who want to start from scratch didn't have this problem, as they start with an empty bank I suppose).

Thanks by advance.

[Mettyk25jigsaw]

Try This Patch   http://forum.metroidconstruction.com/index.php?action=dlattach;topic=145.0;attach=2264

Don't forget to patch JAM'S 'reserve energy safety fuse' patch prior to patching Plm repoint patch found here   http://metroidconstruction.com/IPS/JAMReserveEnergySafetyFuse.rar

Also I assume it's version 1 you use above for the reserve energy safety fuse patch otherwise try version 2 found here   
http://metroidconstruction.com/IPS/JAMReserveEnergySafetyFuseV2.rar

1 Last thing---Remember to BACK-UP B4 doing any of these patches....

[P.JBoy]

What you did with the patch sounds like it should have worked. With regards to the ASM, what version of xkas are you using, and how sure are you that the data is being read from $8F? Also, completely ignore the $01:6B6E  ;  $02:04AC ; $02:0B60, that was for an old broken patch; that said, SMILE v2.5 won't recognise to use a different bank unless you change those values, thus, this is actually not a working SMILE feature (my fault); but propagating changes to the new bank manually will work fine

[BigDomino]

@ P.JBoy :
Hi,
The version of xkas I used is xkas v14 (by byuu).
I get this version some years ago (it was a bz2 file called : xkas_v14.tar.bz2 ).
In the "doc" subfolder of xkas, is a html document of the author :
[spoiler]xkas v14
Author: byuu
License: public domain

Command line:
xkas -o output.bin input.asm [second-input.asm ...]

If the output file exists, xkas will assemble the source file on top of this file. If it does not exist, xkas will create the file.

Usage examples:
xkas -o output.bin input.asm
xkas -o output.bin input1.asm input2.asm
xkas input1.asm input2.asm -o output.bin

Commands:
arch type

Select processor architecture.

Supported values:
none - None; uses base commands only
gba.thumb - GBA THUMB CPU (ARM7TDMI THUMB)
snes.cpu - SNES CPU (WDC 65816)

endian type

Manually specify processor endian. This will affect dw, dl and dd commands. Note that selecting a processor architecture will automatically select endian. This is intended to be used for "arch none" only.

Supported values:
lsb - Little endian
msb - Big endian

incsrc filename.asm

Include additional source file. Note that this command is infinitely recursive. Eg file1.asm can incsrc file2.asm, which can incsrc file3.asm. Recursion is only limited to available memory. The state will remain unchanged, eg all defines and labels will remain in-tact.
incbin filename.bin

Insert binary file directly into output.
org offset

Seek to specified offset. Offset address relativity to output file is based upon the current architecture. Eg if arch = snes.cpu, org should be an SNES-memory-mapped offset. For arch = none, this is a literal offset into the output file.
base offset

Override internal org address when computing eg labels. This is useful for relocatable code and custom address mapping.

Usage example:
org $c02000; base $7f0000
lda #$00
loop:
jml loop //will assemble as jml $7f0002; while writing to pc($c02002)

align modulus

Write 0x00s until offset is evenly divisible by modulus. Eg if offset is $8011, "align 4" will write three 0x00s, aligning offset to a 4-byte boundary; in this case, $8014.
db / dw / dl / dd value [, value, "string", ...]

Simple binary data insertion. These commands additionaly support quote-delimited 7-bit ANSI encoded strings.
db - Data byte (8-bits)
dw - Data word (16-bits)
dl - Data long (24-bits)
dd - Data double word (32-bits)

fill length [, value]

Writes "length" number of bytes to output file. If value is not specified, write value is 0x00.
fillto offset [, value]

Writes until "offset" is reached. If value is not specified, write value is 0x00.
define name "value"

Creates a new define, or overrides a previous define by the same name. Quotes are only needed if space is needed inside the define.

Usage example:
define add "clc; adc"
define health_bonus 32
{add}.w #{health_bonus} //will assemble as clc; adc.w #32

define 'char' value

Redefine string table entry. "char" must be exactly one ANSI character in length, and "value" must resolve to an integer.

Usage example:
define 'C' $1234 //value can be up to 64-bits in length
lda.b #'C' //will assemble as lda.b #$34
lda.w #'C' //will assemble as lda.w #$1234
dw "C" //will write #$1234 to output


label:

Creates a new label. Can start with _[A-Za-z], can contain _[A-Za-z0-9].
.sublabel:

Creates a new sublabel. Must start with ., can contain _[A-Za-z0-9]. Sublabel is automatically prefixed with the most recently specified label. Example:
label:
.sublabel: //will assemble as label.sublabel

+ / - label:

Creates a nameless label. Will ignore active namespace. + is used to point to a label after the current code position, - is used to point before the current position. Can be redefined at any point in the code. Example:
-; dex; beq +; ...; bra -
+; rts

namespace name

Sets the active namespace. When a label, sublabel or define is specified without a namespace prefix, it is automatically prefixed by the active namespace. This defaults to "global". Note that unlike C++ namespaces, this function is not recursive. There is only one namespace level. Example:
namespace global
label:
.sublabel:
define def "0"
dw label, .sublabel, custom::label, custom::label.sublabel, {def}, {custom::def}

namespace custom
label:
.sublabel:
define def "1"
dw label, .sublabel, global::label, global::label.sublabel, {def}, {global::def}

print arg [, arg, "string", ...]

Prints specified message to the terminal. Example:
org $8000
label1:
print "label1 offset = ", org //prints "label1 offset = 0x8000" [/spoiler]

After my unsucessful attempts, I tried to found and re-download xkas v14 from byuu page but it seems to be unavailable now (idem from ROMhacking.net).

To answer your second question : To be sure that data is being read from bank $8F I made a copy of the patched hack.
In this copy, I changed the type of some PLM, then did a file compare via HxD and see that all the modified data were located in bank 8F.

I'm not sure to understand your last sentence (English is difficult for me).
Did you mean that, althought the patch is correctly applied, there will no more be possible to manage PLM directly from smile (type , position , Hi-low index )?

As long as I use smile 2.5 , which adresses should be changed ?

I'm sorry, I did'nt understand your explanation about "propagating changes to the new bank manually"

If the patch was installed sucessfully (which is apparently not the case for my hack), is it expected that the plm bank (in Smile pointer pop-up) is changed automatically (8F become E2 for example) or, after applying the patch, should the user have to manually change the pointers given by Smile? (...pffff  i cannot write this question in a comprehensible way...)

Thank you very much for taking the time to answer and forgive me for my english.

@ Mettyk25jigsaw :

Thanks for your answer,
I already knew this patch by Jam, but I read in the description that other patchs have to be installed in order to make this one working and (if possible) I really want to avoid installing no-needed patch  :cry:

Anyway, thanks for your help.

[P.JBoy]

Basically. The bank changing feature in SMILE doesn't work. If you want to use another bank, you'll have to apply the patch and use a hex editor to write the data to $E2 manually. Also, good, you have the correct version of SMILE

[BigDomino]

Thanks for your explanation - I think I get the idea,

In other words, after the patch was applied, Smile is still reading and displaying PLM data and scroll PLM data from original bank 8F while the game, when played via emulator, actually read data from the new bank.
Bank number specified in gray box in Smile pointer pop-up don't reflect the real bank from which the game will read PLM data ?

( If the previous assertion is correct, the following observations should be too )

Consequently, within the limits of free space in original bank 8F, the hacker could still edit the PLMs in Smile (positioning ; high / low index ; type) then, via Hex editor, grab the modified PLM data in 8F and paste it in the corresponding place in the new bank.
At that point, it's even possible to make PLM data in $8F and in the new bank exactly the same to keep a visual track in Smile of how the PLMs are sorted in the room.
Re pointing (to free space) or pointer inversion (between two room) are, in the other hand, no more doable in Smile as long as Smile assume that data are Still in 8F.

When all the free space is (virtually) consumed in $8F, the additional needed PLMs data could be manually written in the new bank at various place (there is a lot of free space there) but, given that smile don't read his data from the new bank, it is other non-PLM-related data that will be displayed instead by Smile from the corresponding offset in 8F....
... it should be preferable to turn off the PLM layer to avoid seeing the room filled with junk data (-> unknown PLM) or to accidentally move one of these unknown PLM which amount to corrupt the very data.

So, the only way I could imagine to configure these additional PLM via Smile would be to keep a free place in 8F that could become a transitional address intended for PLM management - this address could be used room after room to set correctly PLM - then the data generated at this address in 8F can be grabbed via hex editor and pasted at their real place in the new bank - finally, transitional address have to be cleared for the next room - and address pointer should be changed for the correct place.
Subsequent modifications of these additional PLMs (after modification of the level design for example) can only be made : A) blindly via hex editor.  or B) With Smile support, but only by going past again the transitional address.

About scroll PLM data :
If I understand correctly, after applying the patch, every scroll PLM touched by Samus will trigger their code located at $ [new bank] : [high index of the PLM] [low index of the PLM].
Managing Scroll PLM data in a new bank (not handled by smile) should not be a problem for hacker accustomed to write manually their scroll data - on the other hand, those who work via the scroll editor will encounter the same difficulties than for PLM data, as described above.
Just to be sure, normal scroll data and door scroll ASM instructions are not affected by the patch, it isn't ?

About patching with the .asm file :
With your explanation, I still think that my ROM was not properly patched (don't know why, though):
Indeed, like described in my first post in this tread, I patched my hack with the .asm, then duplicated whole bank 8F in bank E2 and do various test.
If I edit a PLM in smile, data are changed in bank 8F (and I'm agree with you that it's not a proof that bank E2 is not used - just the demonstration that Smile still read PLM data from $8F and continue to edit the data at this original place) but if I quickmet in this room, where the PLM was edited (in bank 8F from Smile) - for example a missile turned into power bomb - I see the edited PLM (the Power bomb) although the unedited bank E2 still contain a missile PLM.
The same thing happens in a regular playing via emulator.
Bank E2 is not read by the game - I've even tested to erase all data in bank E2 and I'm still able to see the PLM in-game or via quickmet.

About patching with the .ips file :
From your explanation, I understood that the 3 pointers at
-> $01:6B6E (pc)  ;  $02:04AC (pc)  ; $02:0B60 (pc) were part of a ineffective feature in Smile and shouldn't be considered anymore.
But what's about the 3 other pointers mentioned in the description of your .ips patch ?
-> $01:68CA (pc)  ;  $01:6B79 (pc)  ;  $01:6B7D (pc)

And do you have an idea about the PLM bank strangely turning to $A8 in pointer pop-up after patching ?

About xkas v14 :
Could somebody tell me were I can get a clean version of xkas v14 ?

Thank you, guys, for your help.

[DSO]

The pointers in SMILE can be correctly used, the problem is that the changes aren't all that's needed.

However, there are still issues. If you want to add PLMs, you must copy a pointer's data with a hex editor that has the number of PLMs you need for the room. If you try changing a pointer and saying you want to save the data to the new location, it saves the data to $8F instead of your chosen bank. Also, using the PLM +/- window writes data to $8F instead of the chosen bank as well.

[P.JBoy]

Just to be sure, normal scroll data and door scroll ASM instructions are not affected by the patch, it isn't ? <--- Indeed

But what's about the 3 other pointers mentioned in the description of your .ips patch ?
-> $01:68CA (pc)  ;  $01:6B79 (pc)  ;  $01:6B7D (pc) <--- Those are the bytes you need to change to $E2 after applying the patch

Here's a clean xkas 14

[BigDomino]

@PJBoy :

Thanks for the link to xkas and sorry for the late reply.

I just tried to re-patch my hack with the clean xkas v14 version but the result is the same than previously.
I also tried to apply the patch on a clean Super Metroid (JU) [!].smc ROM (with a new bank E2 added) in vain...

After patching these expected things occurs :

- Smile still read PLM data from bank $8F.
- Bank specified in gray boxes is still $8F.
- PLMs modification done in Smile cause changes in bank $8F (visible in real time via hex editor).

But these unexpected things also occurs :

- Changes to PLM, done via Smile in bank $8F, are visible when the game is played via Quickmet.
- Sames thing occurs with regular playing (game started in emulator from the beginning).
- The supposed new bank is not used in any manner : PLMs are presents in-game even if the new
   bank was left (intentionally) empty.

Finally I tried to re-patch another time.
This time, I changed the name of the ROM and of the patch like this:
test.smc   &   test.asm
Then, I launched the "test.asm test.smc  .bat" file given with xkas.

This time, some changes are visible in smile... bank 8F is now changed for bank A8 in pointer pop-up...
(just like with the .ips patch).

But, even if the patch is not working properly, this third try showed me that my first method
for patching was wrong (but why ?)

and what's happens with bank A8 ?

Am I the only user of this patch who encounter this problems ?

Thank you for your help.
- - - - - - - - - - - - - - - - - - - - - - - - -
@ DSO

Thanks for the info.

The pointers in SMILE can be correctly used, the problem is that the changes aren't all that's needed.

-> How do you set the pointer correctly in the first place ?
-> What are the other things needed ? Are you referring to the restrictions listed below your picture
    or other things ?

However, there are still issues. If you want to add PLMs, you must copy a pointer's data with a hex editor that has the number of PLMs you need for the room. [ ... ] Also, using the PLM +/- window writes data to $8F instead of the chosen bank as well.

-> Adding PLM via hex editor (instead of PLM +/-) shouldn't be an insurmountable problem, if it's still possible to edit them via Smile.

If you try changing a pointer and saying you want to save the data to the new location, it saves the data to $8F instead of your chosen bank.

-> When you say "a pointer" do you mean "any pointer" or "a PLM pointer" ?
For example, if my room use PLM data stored in the "new" bank (at $E2:C116) and I want to relocate the enemy pop data from $A1:EB98 to free space at $A1:EBD1.
If I change the enemy pop address in Smile pointer pop-up and choose "save the data to the new location", the data stored at $E2:C116 will, at the same time, overwrite those stored at $8F:C116 (which are FX2 data") ?
That should be really annoying....  :pale:

[P.JBoy]

Where you have managed to patch it so that SMILE shows that you're apparently using bank $A8, that's good, that's what my patch should cause to happen. The problem is that SMILE doesn't work with PLMs after you apply the patch, because of the broken system that it uses.

If you use an old version of SMILE (before that bank switching feature became available), then even after applying the patch, PLMs will display correctly in SMILE, and any changes you make will be done to bank $8F and NOT bank $E2.

All we can hope for here is that JAM will incorporate these PLM bank changes into his branch of SMILE some time so that this process isn't so ridiculous

[BigDomino]

I see,

But just to let you know, after it was patched, the game freezes after Ceres explosion cutscene (just before landing on Zebes). It happens with both .ips & .asm version of the patch.

I think It should be better for me to wait this PLM feature to be fully handled by SmileJX before going any further.

One last question:
If I want to use the patch only to relocate Scroll PLM instruction (PLM data will stay in bank $8F), will I even so loose Smile assistance for PLM at the same time (and will I go into all the problems described in our previous post of this tread) or will I be able to work on PLM as usual?
In this view, what should I do after applying the patch to remove bank A8 from pointer windows and going back to $8F ?

Thanks for your explanations and for your time.