80b903 jsl $bc904b [bc904b] A:0000 X:0001 Y:0004 S:013f D:0000 DB:81 nvMXdiZc V: 17 H:1170
bc904b rep #$20 A:0000 X:0001 Y:0004 S:013c D:0000 DB:81 nvMXdiZc V: 17 H:1224
bc904d lda $009c [81009c] A:0000 X:0001 Y:0004 S:013c D:0000 DB:81 nvmXdiZc V: 17 H:1242
bc9050 asl a A:5160 X:0001 Y:0004 S:013c D:0000 DB:81 nvmXdizc V: 17 H:1276
bc9051 clc A:a2c0 X:0001 Y:0004 S:013c D:0000 DB:81 NvmXdizc V: 17 H:1288
bc9052 adc $009c [81009c] A:a2c0 X:0001 Y:0004 S:013c D:0000 DB:81 NvmXdizc V: 17 H:1300
bc9055 xba A:f420 X:0001 Y:0004 S:013c D:0000 DB:81 NvmXdizc V: 17 H:1334
bc9056 sep #$20 A:20f4 X:0001 Y:0004 S:013c D:0000 DB:81 NvmXdizc V: 17 H:1352
bc9058 sta $009d [81009d] A:20f4 X:0001 Y:0004 S:013c D:0000 DB:81 NvMXdizc V: 18 H: 6
bc905b clc A:20f4 X:0001 Y:0004 S:013c D:0000 DB:81 NvMXdizc V: 18 H: 32
bc905c adc $009c [81009c] A:20f4 X:0001 Y:0004 S:013c D:0000 DB:81 NvMXdizc V: 18 H: 44
bc905f sta $009c [81009c] A:2054 X:0001 Y:0004 S:013c D:0000 DB:81 nvMXdizC V: 18 H: 70
bc9062 rtl A:2054 X:0001 Y:0004 S:013c D:0000 DB:81 nvMXdizC V: 18 H: 96
... this should be a totally deterministic sequence independent of everything you do. In other words, unless something manually resets it, the only way you can influence the RNG is changing when the decision is made. ie/ a boss fight should go the exact same way every single time, so long as you start it on the same frame (and the RNG began rolling on the same frame) (unless you can change when they make a decision by hitting them at a different time or something). Upon thinking about it some more, it's entirely possible the AI's decision-making could be based on both RNG and something like your position as well. But at least you know where the random element comes from. It seems to be initialzed with value $0D37 and starts running on frame 694 in your file, though it pauses during the lag frames / loading time.
OK guys, here's the deal with Ovnunu (I know I've already explained this elsewhere, but bear with me): His slime pulses up and down during the phase where you kill the mini-eyes. Whenever he reaches his lowest point of the pulse, the game checks to see if the mini-eyes are all dead. If they are, he comes out. If not, he goes into another pulse cycle. Each pulse cycle lasts about 300 frames. Now, in my current run, this phase lasts for about 1200 frames (4 pulses). As I hypothesized earlier, it may be possible to shorten this phase to 900 frames (3 pulses). I've gotten quite close with random testing, but it's unfortunately quite tedious. What I'm wondering is if anyone is willing to help me find out what causes these eyeballs to come out and when (the memory addresses, or if some as-of-yet-unknown RNG *shudder* is the cause)....
...I found that 7E1DF8 is a counter for eyes that Firebrand has killed. This address is read at $83/D20C, and I'd bet the function you're looking for isn't too far off....
....I did discover that values 7E1DE7 - 7E1DDE are the true/false values for the eyeballs. They all start at 9, and the moment an eyeball decides to come out, the value turns to 0. Now, I really don't know what I would do with this information, but I'm sure it's of importance to the search. The frustrating thing is, there's got to be a whole lot I'm missing. For example, depending on which frame the slime reaches the top of the vertical passage, different amounts of eyeballs will come out at different times. Also, I think some of the eyeballs are "linked," meaning that the next eyeball in the sequence won't emerge until it's linked eyeball has been defeated (I specified this because I thought at first the game just put a general limit on how many eyes could be out of the slime at one time)....
83/D3B9: E230 SEP #$30 ; set bits x, d, i, ; and z = 1 83/D3BB: A542 LDA $42 ; load the accumulator ; with memory, also ; deals with Direct Page? 83/D3BD: F044 BEQ $D403 ; something to do with a ; branch to 83/D403? 83/D3BF: 220F8882 JSR $82880F ; jump to subroutine at ; 82880F (not sure what ; this means) 83/D3C3: 903E BCC $D403 ; clear the carry bit at ; D403? 83/D3C5: A636 LDX $36 ; Load X register from ; direct page 83/D3C7: AD820D LDA $0D82 ; Load the accumulator ; with memory at 0D82 83/D3CA: 38 SEC ; set bit c = 1
Not quite. The sigil ($) means we're using hexadecimal. Decimal 30 = 00011110, which is how you got nvmXDIZc, whereas $30 = 00110000 = nvMXdizc. You can find out more about this by searching "flag register" in the asmtutor, but what SEP #$30 does is set the M and X flags, both of which tell the CPU that we're working in 16-bit mode, rather than 8-bit mode. The sharp (#) means that rather than loading an address, it's using an absolute value. I should also tell you about Geiger's debugging snes9x. If you don't already have it, you should get it, because it allows you to step through the code as it's being executed.83/D3B9: E230 SEP #$30 ; set bits x, d, i, ; and z = 1Loads the accumulator with whatever is in 7E0042. I don't think the direct page actually comes into play when digging around in disassembly. At least, I've never seen it.83/D3BB: A542 LDA $42 ; load the accumulator ; with memory, also ; deals with Direct Page?Branch if EQual checks to see if the zero flag is set, and if it is, it jumps to the address given, within this code bank. (The ROM is divided into chunks or "banks" of (IIRC) $8000 bytes. We're looking at bank $83 right now, hence the jump to $83/D403.)83/D3BD: F044 BEQ $D403 ; something to do with a ; branch to 83/D403?If the z flag wasn't set at the BEQ, the processor will proceed to this line, and jump unconditionally to $82/880F, which is code bank $82. Once there, it executes whatever it finds until it hits the RET code, and returns to $83/D3BF. If you need to see what bank $82 (or any other bank) does, Modify that batch file to dump it by changing "83" to the bank number and renaming the output file.83/D3BF: 220F8882 JSR $82880F ; jump to subroutine at ; 82880F (not sure what ; this means)Branch if Carry Clear. If the program had, for example, incremented the accumulator until it carried over to the next byte, the carry flag would be set, and it would jump to 83/D403, as with the BEQ above. We don't know by looking at disassembled code whether this branch actually happens or not, or under what circumstances. Hence the importance of Geiger's debugger.83/D3C3: 903E BCC $D403 ; clear the carry bit at ; D403?In addition to the Accumulator, data is often loaded into the X and Y indices. Usually, these are used as loop counters as you would use "int i" in a for loop in C/++. LDX $36 loads 7E0036 to the x index, the contents of which are listed in the disassembly pane of Geiger's debugger.83/D3C5: A636 LDX $36 ; Load X register from ; direct pageRight- and remember that you can find 0D82 in the cheat search by putting 7E in front of it.83/D3C7: AD820D LDA $0D82 ; Load the accumulator ; with memory at 0D82Manually sets the carry flag. It's unclear from what you've posted why it would do this.83/D3CA: 38 SEC ; set bit c = 1
(I think those comments should be correct, though it's still my first day of learning to read disassembly so bear with me). Now, this bit of data isn't of much use, but it did clue me in that I may be getting closer to what I'm looking for. The beginning of this block begins at $83/BC2B, and it (and the next block) contain the values 1DDE,Y and 1DDE,X as well as commands to switch the Y and X values. (remember, 7E1DDE is the address for whether the first eyeball is active or not; I'm assuming that the X and Y after this value will change the address and affect different eyes?).83/BC4E: ADF81D LDA $1DF8 ; Load the accumulator with ; the value at 7E1DF8 (the ; counter for eyes you killed) 83/BC51: C90A CMP #$0A ; and compare it with the ; value 10 83/BC53: D019 BNE $BC6E ; if it isn't equal (i.e. you ; haven't killed all the eyes) ; branch to $83/BC6E
Yes, 7E009C is the random number, which is generated with this algorithm. It's run every frame and it's also run when a random number is needed:The number of eyes that come out at a time is random. When you start fighting, the probability is 50% of 2 coming out, 37.5% of 3 coming out and 12.5% of 4 coming out. There is a 33 frame delay between them. Afterwards, there is a 128 frame delay, and there is: - 12.5% chance of 1 coming out, 50% chance of 2 coming out, 25% chance of 3 coming out and 12.5% chance of 4 coming out with 0 eyes out, - 37.5% chance of 1 coming out, 50% chance of 2 coming out and 12.5% chance of 3 coming out with 1 eye out, - 37.5% chance of 0 coming out, 50% chance of 1 coming out and 12.5% chance of 2 coming out with 2 eyes out, - 87.5% chance of 0 coming out and 12.5% chance of 1 coming out with 3 eyes out. Otherwise, no eyes come out. In that case, Ovnunu just waits another 128 frames again, which he also does if all the eyes are already out but haven't been killed yet. So you have to kill the last eye before the next is supposed to come out or you'll have to wait another 128 frames. When it's time to send out another eye and you've killed all 10, Ovnunu will decide to jump out the next time he reaches the bottom. Luck manipulation might be hard since all you have to work with is the amount of eyes killed before it's going to send out more eyes, and the amount of wait frames before you start (Ovnunu begins to wake up when your X coordinate is at least 128 or your Y position is less than 568)BC:904B RNG: ; CODE XREF: _80:A8FAP BC:904B ; _80:AE67P ... BC:904B rep #$20 BC:904D .ACCU 16 BC:904D lda RandomNumber BC:9050 asl A BC:9051 clc BC:9052 adc RandomNumber BC:9055 xba BC:9056 sep #$20 BC:9058 .ACCU 8 BC:9058 sta (RandomNumber+1) BC:905B clc BC:905C adc RandomNumber BC:905F sta RandomNumber BC:9062 rtl
Boss hp is at 7E1336 for most bosses. Memwatch that to learn a lot. It looks like that boss may be a special case. I checked on Arma and it turns out there is a check before the hit. It checks to see if the high bit of that hp address is set (with a bpl instruction). In other words, the invulnerability flag is packed into the same byte as the hp. For some reason that flag is never set for hippogriff. Memwatch that hp and you'll see that several other bosses are vulnerable. In most cases this just means that a ground gargoyle shot hits twice. Somulo doesn't set that bit but there is something else going on because he dies at 1 hp instead of 0. Arma's invulnerability timer is at 7E1DD5, but that doesn't seem to be the case for other bosses.
You shouldn't need a degree in computer science to get into this hobby.
