chaos

It's up to you whichever weight bug fix you'd like to do. But if you want to do this one, yeah, I would remove the WBF and then change the bytes

I think that's $30E. Maybe it is different in the 32 team ROMs? I looked, I don't know what it's trying to do with $30A. Right before it enters the routine where it's crashing, it is setting A2 and A3 to the start of the team structs. EDIT: Looks like A2 is set to $30A in 12 spots, and in all cases, few instructions after, there's a call to doBitMap. EDIT2: OK, when looking at the 92 source code, there are instances before doBitMap called, a2 is set to #null. null is a long variable set to 0. At $30A, it is a long word of 0.

The penalties were already in 94, so there was no change done there. Fighting* is the winning fighter, Fighting is for the one who lost

Weird, because this code is before the call to $12A2E subroutine: updatepwrplay: ; CODE XREF: periodiceevents+46↑j ROM:00012A7C 0838 0001 C2FA btst #1,(word_FFC2FA).w ROM:00012A82 6600 29E0 bne.w rtss2 ROM:00012A86 347C C6CE movea.w #(HmShots-M68K_RAM),a2 ROM:00012A8A 47EA 0364 lea $364(a2),a3 ROM:00012A8E 302A 0024 move.w $24(a2),d0 ; tmap ROM:00012A92 906B 0024 sub.w $24(a3),d0 ROM:00012A96 6700 009A beq.w _clrpwrplay ; teams have same # of players on ice ROM:00012A9A 6A00 001A bpl.w _t0 ROM:00012A9E 0838 0006 C2EE btst #6,(sflags2).w ; #sf2pwrtm - 0 for team 1, 1 for team 2 ROM:00012AA4 6600 0026 bne.w _upp ROM:00012AA8 6100 0088 bsr.w _clrpwrplay ROM:00012AAC 08F8 0006 C2EE bset #6,(sflags2).w ROM:00012AB2 6000 0018 bra.w _upp ROM:00012AB6 ; --------------------------------------------------------------------------- ROM:00012AB6 ROM:00012AB6 _t0: ; CODE XREF: updatepwrplay+1E↑j ROM:00012AB6 C54B exg a2,a3 ROM:00012AB8 0838 0006 C2EE btst #6,(sflags2).w ROM:00012ABE 6700 000C beq.w _upp ROM:00012AC2 6100 006E bsr.w _clrpwrplay ROM:00012AC6 08B8 0006 C2EE bclr #6,(sflags2).w ROM:00012ACC ROM:00012ACC _upp: ; CODE XREF: updatepwrplay+28↑j ROM:00012ACC ; updatepwrplay+36↑j ... ROM:00012ACC 08F8 0005 C2EE bset #5,(sflags2).w ; #sf2pwrplay - turn on PP ROM:00012AD2 6600 0014 bne.w _uppt ROM:00012AD6 526B 0004 addq.w #1,4(a3) ; tmpwrplays ROM:00012ADA B6FC C6CE cmpa.w #$C6CE,a3 ; check if a3 is home team ROM:00012ADE 6600 0006 bne.w _away ROM:00012AE2 ROM:00012AE2 _home: ; CODE XREF: updatepwrplay:_away↓j ROM:00012AE2 6000 0004 bra.w _uppt ROM:00012AE6 ; --------------------------------------------------------------------------- ROM:00012AE6 ROM:00012AE6 _away: ; CODE XREF: updatepwrplay+62↑j ROM:00012AE6 60FA bra.s _home ROM:00012AE8 ; --------------------------------------------------------------------------- ROM:00012AE8 ROM:00012AE8 _uppt: ; CODE XREF: updatepwrplay+56↑j ROM:00012AE8 ; updatepwrplay:_home↑j ROM:00012AE8 6100 F0A8 bsr.w printz ROM:00012AE8 ; --------------------------------------------------------------------------- ROM:00012AEC 0000 dc.b 0 ROM:00012AED 0012 dc.b $12 ROM:00012AEE 00BF dc.b $BF ROM:00012AEF 0001 dc.b 1 ROM:00012AF0 0019 dc.b $19 ROM:00012AF1 0020 dc.b $20 ROM:00012AF2 0020 dc.b $20 ROM:00012AF3 0020 dc.b $20 ROM:00012AF4 0016 dc.b $16 ROM:00012AF5 0017 dc.b $17 ROM:00012AF6 0018 dc.b $18 ROM:00012AF7 0019 dc.b $19 ROM:00012AF8 00BF dc.b $BF ROM:00012AF9 0001 dc.b 1 ROM:00012AFA 001A dc.b $1A ROM:00012AFB 0020 dc.b $20 ROM:00012AFC 0020 dc.b $20 ROM:00012AFD 0000 dc.b 0 ROM:00012AFE ; --------------------------------------------------------------------------- ROM:00012AFE 6100 FF2E bsr.w sub_12A2E Which does what you put into the $12A2E routine. The data after printz is a string so you can ignore that. So maybe there is something strange going on there?

Going into that subroutine starting at $12A2E, A2 is the start of the Home Team Struct ($C6CE) or the start of the Away Team Struct ($CA32), depending on who has the PP (A2 is the team on the penalty kill). The other team struct (PP team) will be in A3. D0 is the end result in seconds and is returned from the function and used to calculate the displayed time. ; a2 = team struct on PK ROM:00012A2E ; a3 = team struct on PP ROM:00012A2E ROM:00012A2E CalcPenTime: ; CODE XREF: updatepwrplay+82↓p ROM:00012A2E 4240 clr.w d0 ROM:00012A30 4243 clr.w d3 ROM:00012A32 41EA 009A lea $9A(a2),a0 ; Move penalty box list start into a0 ($C768 for Home, $CACC for Away) ROM:00012A36 ROM:00012A36 _getstatus: ; CODE XREF: CalcPenTime+18↓j ROM:00012A36 ; CalcPenTime+20↓j ROM:00012A36 4242 clr.w d2 ROM:00012A38 1418 move.b (a0)+,d2 ; move value at a0 (then increment) into d2 ROM:00012A3A 6B00 0014 bmi.w _endoflist ROM:00012A3E 3432 2066 move.w $66(a2,d2.w),d2 ; move status of d2 player into d2 (pen time) ROM:00012A42 0802 000E btst #$E,d2 ; test bit 14 if set ROM:00012A46 66EE bne.s _getstatus ; branch if set (player on ice, injured, on bench) ROM:00012A48 9443 sub.w d3,d2 ; sub d3 from d2 ROM:00012A4A D042 add.w d2,d0 ; add d2 to d0 ROM:00012A4C 3602 move.w d2,d3 ; move d2 into d3 ROM:00012A4E 60E6 bra.s _getstatus ; loop till end of list ROM:00012A50 ; --------------------------------------------------------------------------- ROM:00012A50 ROM:00012A50 _endoflist: ; CODE XREF: CalcPenTime+C↑j ROM:00012A50 0C6B 0006 0024 cmpi.w #6,$24(a3) ; checks how many players are on ice (6 = everyone) ROM:00012A56 6700 2A0C beq.w rtss2 ; exit if so ROM:00012A5A 9043 sub.w d3,d0 ; sub d3 from d0 ROM:00012A5C 41EB 009A lea $9A(a3),a0 ; same as above, opposite team ROM:00012A60 4242 clr.w d2 ; clear d2 ROM:00012A62 ROM:00012A62 _getstatusopp: ; CODE XREF: CalcPenTime+40↓j ROM:00012A62 1418 move.b (a0)+,d2 ROM:00012A64 6B00 29FE bmi.w rtss2 ROM:00012A68 0833 0006 2066 btst #6,$66(a3,d2.w) ; check if bit 6 is set (pen time 64 sec+) ROM:00012A6E 66F2 bne.s _getstatusopp ; branch if set ROM:00012A70 B073 2066 cmp.w $66(a3,d2.w),d0 ; compare pen time a3 to d0 (total time for PP) ROM:00012A74 6D00 29EE blt.w rtss2 ; exit if less than ROM:00012A78 D043 add.w d3,d0 ; add d3 to d0 ROM:00012A7A 4E75 rts ROM:00012A7A ; End of function CalcPenTime

Yeah, could be that. I'm thinking anything out of the range (0-25). If it's outside the range, it will pick up a different value and can't do the right math with it.

The instructions at $12A40 have to do with player status. The code will keep track of each player's status (injury, on bench, on ice, penalty box time). -4 = injury for game -3 = injury for period -2 = bench -1 = on ice 0+ = penalty box time (in seconds) What it is trying to do is get how much time is left so it can display the PP time. I wonder if it's a problem related to # of players on the team, or if it's more reproducible with more than one player in the box for a team. EDIT: Yeah I tested with breakpoints, at RAM locations $C768 (Home) and $CACC (Away), it stores the player offset of the players in the penalty box (1 byte each, ends in $FF). This is used in the subroutine to get the player's status (in this case penalty box time, which 2 minutes = 120 seconds $78). It will check and make adjustments based on how many players are in the box and their time left. So there must be an issue with the number of players, as there will only be space for status for 26 players.

correct

No, the 127 is just to mean there can't be a penalty. So the subroutine returns a value that is used for a comparison. Since there can't be a no hitting penalty on a team that has a PP coming up (delayed call on the other team), the subroutine returns a 127 instead of the RNGed value.

No the 127 fixed value is just for the penalty probability comparison. When a guy is checked and falls down, value needs to be 3 or less for penalty. When a guy is checked and stays up, 4 or less for penalty. When a guy is hooked 6 or less. All the 127 is doing is making sure it passes that penalty probability check as no penalty

I updated my repo yesterday. It has a new LST file you can open up in a text editor and look through the code with my comments.

You mean the 127 value? No, that's just to make sure during a delayed call that there's no coinciding action penalties. The team who is going on the PP can still get an interference penalty or penalty from injury, but can't get any others. The 127 just insures it's not below the compare limits.

Nice chart! I'm confused about the "Make Up" Calls though. What are you using to determine that?

I'm interested in what you found. Sometime last year I analyzed this code, just haven't posted yet. When penalties are off: The B check is less effective, because a calculation is done using the Chk rating of the player throwing the B check, and the Agl of the player being checked. RNG is also used. If its a CPU player throwing the B check, this calculation is ignored and it would work just like if penalties are off. Calculation (used when penalties are Off, and the player checking is controlled by a joypad): - Start with 32 decimal - Add Chk rating (0-30 dec scale) of checking player - Sub Agl rating (0-30 dec scale) of player being checked - Subtract 2 from result (this is due to crowd meter bug, it's always active) - New result = RNG (between 0 and the result above) - If new result is less than 24 decimal, exit (unsuccessful B check) If penalties are on, or it's a CPU player B checking, or the above calculation deemed it was good enough to continue: - Get difference of the 2 players in X (X_checking - X_checked) - Get difference of the 2 players in Y (Y_checking - Y_checked) - Use those results to get a direction (Ex: If checking player is directly to the right of checked player, their Xpos is more positive than the checked player, the X difference will be positive. If the checking player is directly above the checked player, their Ypos is more positive than the checked player, so Y difference will be positive). This is used to determine where the checking player is relative to the checked player. The result will be 0-7 (0 would be above the checked player, 2 would be to the right, 4 below, 6 to the left) - Subtract the checked player's direction from the above. - Add 1 to the result - Pass the first 3 bits (to make sure the result will be between 0-7) - Compare the result to 2. If higher than 2, B check is unsuccessful. - If lower than or equal to 2, code will enter the Fall Down routine - After Fall Down routine, it will check for penalties using the Aggression attribute (check the thread on Penalties for this). It will check if the calculated result is more than 4. If so, no penalty, if less than or equal, Tripping penalty. For Example: - Player is joypad controlled, penalties on (bypasses the Chk-Agl calc) - Checking player is above and to the right of the checked player. His position is top right of the checked player, which would result in a 1 after checking the positions. (Think 0-7 direction going clockwise, where 0 would be directly above). - Sub the checked player's direction. Let's say the player is facing up (again 0-7 for direction CW, facing up is 0). So his direction value is 0. So 1-0=1 - Add 1 to the result. 1+1=2 - Pass the first 3 bits. In this case, it doesn't matter, since our result was <= 7. We still have 2. - Compare to 2. We are equal to 2, so the check is deemed "successful" and we enter the Fall Down routine. On return, it will check for a penalty. Let's use same above, but checking player is now directly to the right of the checked player (so direction would be 2). Checked player is still facing up. - Sub checked player's direction - 2-0 = 0 - Add 1 to the result. 2+1=3 - Compare that to 2. We are higher than 2, so we will exit the routine. Also, there will be no check for a penalty here. Note, this is just the checking part. Has nothing to do with stealing the puck. This is to determine if the player will fall down (or have a chance to toddle) from the B check. But when the player falls down, they lose the puck possession, and with the checker's stick close to the puck, they have a chance to collect it. The other part of B checking where you steal the puck is different, it relies on the Stk rating of both players, and penalties on/off don't make a difference there. This other part also just happens if you bump into the player and the puck is near your player's stick.

The Save RAM uses addresses in the $200000 range. Did you relocate it, or change the save ram bit at runtime? Maybe it doesnt really matter, since the "Leave Off!" is left off (User Records)