[SM] some ASM questions

[Vener]

Hello everyone ,

I'm in trouble for coding stuff at 4 points , so i'm looking for some help .

1- What is the value used to check if a super missile is fired on screen by Samus ?
And it is possible to check constantly how many frames this projectile exist from the time where it was spawned until the time where it will be deleted ? 

2- It is technically possible to set controlls without actually pressing/holding them ?
I mean ; for exemple , let's say Samus touching a BTS that set 'Jump' automatically one time , without pressing jump touch ...?
I tried something like
LDA $09B4
LDA #$0800
STA $09B4

But that do nothing .

3- How the values in momentum tables at :

$90/9F55 - $90/A08C (Air)
$90/A08D - $90/A1DC (Water)
$90/A1DD - $90/A32C (Lava/acid)

are called ? They seems hard to check independently without rewriting an entire table ..   

4- And finally , About GFXs in $84
For extension packs that use CRE gfx , i know that the format is a frame value + a pointer to a tilemap in $84 with format :
AA, BB
XXXX, XXXX, XXXX....
CC, DD
AA, BB
XXXX, XXXX, XXXX....
$0000

AA = 00 or 80. This is the direction to draw blocks. 00 is horizontal, 80 is vertical.
BB = number of XXXX tiles to draw in current direction
CC = horizontal offset to add to current position of drawing blocks
DD = vertical offset to add to current position of drawing blocks
XXXX = tile data
YYYY = tile data

That can be repeated as many time as we need ...

But , for the items that uses GFX at $48000 in TLP, the routine seems to be strict with the format (a pointer that read 2 tiles + 8 bytes for the palletes) , and i have to get some items that use the pointer for reading 3 tiles + 12 bytes for palletes , so any idea of what is the routine that set up the item PLM's GFX format ?

[Quote58]

Hello everyone ,

I'm in trouble for coding stuff at 4 points , so i'm looking for some help .

1- What is the value used to check if a super missile is fired on screen by Samus ?
And it is possible to check constantly how many frames this projectile exist from the time where it was spawned until the time where it will be deleted ? 

Yes, first check each projectile and see if it's still live, then check if it's a super. Those are both flags carried by each projectile in the projectile type array.

7E:0C18 - 7E:0C2B    Projectile type array. 8000+ = live(?), X0YY = beam, YY = beamtype, X1XX = missile, X2XX = super missile, X3XX = power bomb, X5XX = bomb, X7XX = dead beam, X8XX = dead missile/super. First 5 slots used for beams/missiles, last 5 for bombs

setting a counter when it's fired (you need the firing routine for that, look in $91), and then counting until it is deleted shouldn't be too hard.

2- It is technically possible to set controlls without actually pressing/holding them ?
I mean ; for exemple , let's say Samus touching a BTS that set 'Jump' automatically one time , without pressing jump touch ...?
I tried something like
LDA $09B4
LDA #$0800
STA $09B4

But that do nothing .

It doesn't do anything because you're not changing the correct thing. $8B and $8F are the held/pressed button addresses respectfully. However if you just want to make samus jump, you can do that without pressing any buttons, and it would also allow you more control.

[Vener]

Thanks for clearing this out , it helps a lot !

[Crashtour99]

3- How the values in momentum tables at :

$90/9F55 - $90/A08C (Air)
$90/A08D - $90/A1DC (Water)
$90/A1DD - $90/A32C (Lava/acid)

are called ? They seems hard to check independently without rewriting an entire table ..   

The reason they seem hard to check is because the main physics routine runs several subroutines based on movement type.  Since there are $1B (hex) movement types, that is a whole lot of routines that have the possibility of accessing these tables.  From the partial disassembly I've done of the physics engine, each movement routine for any specific movement type accesses these tables independently.  If you want to change this, you really have 2 options:
1) Rewrite the physics engine, which could take quite a while since it is extremely un-optomized (though it IS organized pretty well).
2) Hijack the routines that set the starting index for the tables, so that those many physics routines check a new table that you've written.  This would be the simpler and easier method, costing not much space in the long run.

Relevant info for option 2:  (from my physics table asm)
;JSR $9BD1  [$90:9BD1]   Set $0A6C to #$A08D if affected by water, or #$A1DD if affected by lava/acid.
;   Also, X = ($0A1F * #$0C) + $0A6C when leaving.
;$909BFE A9 8D A0    LDA #$A08D
;$909C06 A9 DD A1    LDA #$A1DD
;entries are indexed by movement type
;The following entries set the starting point for momentum table
;storing base value to $0A6C
;$9497D0 A9 55 9F    LDA #$9F55
;$9498A5 A9 55 9F    LDA #$9F55
;$9498DC A9 55 9F    LDA #$9F55
;$949909 A9 55 9F    LDA #$9F55
;$94992F A9 55 9F    LDA #$9F55

4- And finally , About GFXs in $84

But , for the items that uses GFX at $48000 in TLP, the routine seems to be strict with the format (a pointer that read 2 tiles + 8 bytes for the palletes) , and i have to get some items that use the pointer for reading 3 tiles + 12 bytes for palletes , so any idea of what is the routine that set up the item PLM's GFX format ?

Items that have their gfx stored in the ROM have those gfx transferred via a routine @ $84/8764.  This routine is specifically hardcoded to only transfer a certain amount of information to update the CRE gfx and tiletable as they are stored in VRAM.  Keep in mind that these item's gfx are moved to those dark tiles in the center of the CRE gfx, so if you have more gfx per item, you won't be able to have as many different items in the same room.  Anyway, relevant information is as follows...

;tweaks to $8764 to alter gfx DMA transfer using $D0 table
org $848774
   LDA #$E300   ;v-ram target address *do not change*
org $848779
   LDA #$0470   ;base for byte count, could be any number really.  dunno why they chose that one in particular
            ;stored in $14, then added to and stored in $18 to compare against
org $84877E
   LDA #$03E0   ;indexed location at $7E/A000 (tile table data for CRE A000 to A7FF)
org $84878A
   LDA #$0100   ;how many bytes   *change to #$0180 for 3 tiles, #$0080 per tile
org $848794
   LDA #$0089   ;gfx bank pointer for DMA transfer during v-blank
org $8487AB
   ADC #$0010   ;added to $848779, #$0008 per tile
            ;number of 8x8 palette ID tiles to write to $7E/A000,x * 2

Keep in mind that you'll have to edit the PLMs to get them to use these new gfx as well, but I'm sure you can handle it.   :^_^:

[Vener]

Thanks Crash , that's all the info i needed . You save me !  :grin:

[Vener]

Well , hello again !  :wink:

I re-get some interrogations , and i haven't found solutions in the forum ...

1- Is the BTSs have the same header format than the majority of PLMs (2 pointers , first for main coding stuff , second for misc. instruction pointer chunks ; with INY(s) for skipping argument(s) if there is) ? And anyway , someone know where the BTS header table is located ? I have to disassemble sup.missile/P.bomb/speedbooster/crumbles/ and air spike #02 blocks of them .

2- I wish to use FX2 pointer to code a subroutine that allow to display FireFlea FX in addition to a normal water FX1 in the same room , but i have absolutely no idea where is FireFlea FX code (i'm guessing that no conflicts will be triggered since both uses a different layer#).

3- Hum , this one is highly important to me ; i can't write checks from room event pointer# , like changing the current level data to another while you are in the room , or still the # of the special graphic bitflag of the room from 00 to 01 while you are in the room (Yeah , it could be strange for most of people, i know) . I haven't missed to end code with the 2 INX and the rest of stuff , but all the checks i try doesn't works , however i heard JAM saying that is possible to change those kind of things ...     

4- Well , for this , i'm a bit afraid :S
I absolutely not can end my hack if i can't make Shaktool able to fall if a sup. missile stike a wall , as some little ennemies already does . I got a code from Kej :

Code Select Expand

lorom
org $A3DCA6
JSR $F330

org $A3F330

;E6C8: Left or Right Wall
LDA $1840               ;Duration of screen-shaking?
CMP #$001E              ;1E frames 
BNE END
LDA $183E               ;Type of screen-shaking?
CMP #$0014              ;Type #$14
BNE END ;Checks for wall shaking due to super missile
LDA $0FB2, X            ;Misc enemy ram. Used by most enemy as flags, indexes, counters, etc
STA $7E7806, X ;Save current AI (Unknown, initialized to BF31 by Ceres Ridley)
LDA #$E785              ;
STA $0FB2, X ;Set to falling AI (Misc enemy ram. Used by most enemy as flags, indexes, counters, etc)
BRA START
END:
RTL
;E785: Falling
START:
LDA $7E7802, X ;Uh. Not sure when this was initialized.(Unknown, initialized to BF31 by Ceres Ridley)
STA $12
LDA $7E7804, X          ;Unknown, initialized to 1 by Norfair Ridley, 0 by Ceres Ridley
STA $14
JSL $A0C786 ;Vertical motion
BCC BETA ;Branch if no collision
LDA $0FB4, X ;Check initial speed? (Misc enemy ram. Used by most enemy as flags, indexes, counters, etc)
CMP #$00FF
BNE ALPHA
LDA #$0080
STA $0FA8, X            ;Misc enemy ram. Used by most enemy as flags, indexes, counters, etc
STA $0FAA, X            ;Misc enemy ram. Used by most enemy as flags, indexes, counters, etc
ALPHA:
LDA #$0000
STA $7E7802, X
STA $7E7804, X
STA $7E7808, X ;Clear speeds
LDA $7E7806, X
STA $0FB2, X ;Restore previous AI
RTL
BETA:
LDA $7E7804, X
CMP #$0004 ;Cap speed at 4 pixels per frame
BPL GAMMA
LDA $7E7802, X
CLC
ADC #$8000
STA $7E7802, X
LDA $7E7804, X
ADC #$0000
STA $7E7804, X ;Accelerate due to gravity
GAMMA:
LDA $7E7802, X
BNE DELTA
LDA $7E7804, X
BNE DELTA
LDA #$E6C8
STA $0FB2, X ;... If stopped, set to floor AI? This probably doesn't ever happen
DELTA:
RTL

But , in first , i don't know where in the running AI i could insert this check , and still , according to the fact that this ennemie possess 7 parts , i wonder if this code will be compatible .   

Hope this is clear enough .