Protect practice hack WRAM against x-ray

[idlechild]

I can see why this wasn't done earlier. I'd like to handle the left and right use cases, but I'm only half done. The aim up and aim down use cases aren't worth the effort.

At least I'm learning about x-ray corruption. It looks like it is easy to write 00FF over a lot of values in the $7E9800-$7F1800 range. If Y is negative then values can be written in the $7F1800-$7F9800 range (I think). Values other than 00FF can be written representing the cone of the x-ray, but I think it is harder to control; you might only be able to write dozens of those values whereas you can write thousands of 00FF. I'm not an expert though.

This is not intended as a quick update. This isn't blocking anyone from routing any% glitched or 0% or other categories as far as I know. Plan to include in the next proper release.

Spacetime beam protection did not change; I just moved it to a new file.

[idlechild]

Whew finally done... at least with the facing left and facing right use cases. I have no plans to cover aim up or aim down use cases (I hope 0% isn't using those!). This ate up a lot of bank 91 freespace just covering the left and right use cases.

I may release this in the near future. I'm at least going to share it on the practice-hack discord channel.

[idlechild]

Man... I think I actually am going to have to support aim up... if I'm understanding the 0% document.

If aim up is needed then might as well support aim down. I'm going to need to jump to another bank just to have room for all the logic.

Probably for the best I did left and right first; was easier to motivate myself to finish the first six cases.

[idlechild]

Phew... hope it's correct... honestly I would accept not correct but still works for 0% routing. There's a lot of similarities in the routines so I was often copying a section of one routine to make another, and the number of mistakes I found in the existing routine I was copying from by doing that... maybe I ended up finding them all but I somewhat doubt it.

I did try forcing the new logic to run all the time and tested x-ray while onscreen so at least verified it doesn't blow up doing that. Any% glitched also works. With infohud preservation enabled I was still able to get crashes and once an orange screen while aiming around (aiming up far enough OOB seemed to do it) but the crashes pointed to the HDMA handler and I suspect x-ray is legitimately (same as it would in vanilla) corrupting some memory that HDMA needs and thus the crashes may be representative of vanilla behavior.

Still not planning to push this in the next couple of days, but it might happen over the weekend. There's been a request to add more Update Timers options with multiple people interested, so 2.7.6 release could be around the corner.

[idlechild]

FYI in order to track when Samus lands, at $90:E632, I'm planning to replace:

STA $0DC7 : REP #$30 : BRA $1F

with:

STA $7Exxxx (address tbd) : BRA $1B (so it still runs STA $0DC7 : REP #$30)

While this only runs on frames with downward collision... that's effectively every frame Samus is on the ground... so a lot...

I'm thinking I should remove two NOPs from the artificial lag to account for this. Let me know if you disagree (or if you think we should remove three NOPs). Worth noting this is an 8-bit sta not a 16-bit sta.

[idlechild]

Never mind, realized the REP is redundant since it is followed by PLP. If I move code around a bit so I remove both the REP and the BRA then it makes up for the STA and I don't need to adjust artificial lag.

[idlechild]

Update Timers is done. I'm hoping to push to master later today after some more testing and updating release notes.

[NobodyNada]

FYI in order to track when Samus lands, at $90:E632, I'm planning to replace

That will run every frame when Samus is standing on the ground.

What about hijacking whatever code is responsible for playing the landing sound effect instead?

[idlechild]

I would consider that if I didn't get the CPU back with this method.

[idlechild]

I get lost when people talk about master cycles, but using this reference guides math:
https://wiki.superfamicom.org/65816-reference

Remove REP #$30 (saves 3 cycles)
Remove BRA (saves 3 cycles)
Insert STA (adds 6 cycles assuming it's 16-bit store since I put it after the PLP)

This cycle math isn't the same as master cycles though... I think... anyway I think this is very close to being lag neutral.

[idlechild]

You saw nothing

(instead of warnpc $90E639 org $90E639, I copy-pasted warnpc $90E639, org $90E614, oops)

[InsaneFirebat]

I prefer to pretend that master cycles are a myth, but when I need them, I use this https://novasquirrel.github.io/SnesInstructionCycleTool/ (or breakpoints in Mesen)

[idlechild]

I prefer to pretend that master cycles are a myth, but when I need them, I use this https://novasquirrel.github.io/SnesInstructionCycleTool/ (or breakpoints in Mesen)

Thanks for the link. Looks like the STA is just slightly more expensive than the combined REP/BRA, but we're splitting hairs... on a system built on artificial lag that isn't 100.00% precise to begin with.

I will proceed with the change.