This is an UberASM which draws a timer on the status bar, which counts for how much time you have been in the level. It will pause whenever the game freezes, is paused or when a message box is active. When the level is completed it will stop and change palette to denote that the level has ended. Requires Super Status Bar patch.
You can also disable the timer in upto 5 levels. This might be useful when you don't want the timer running in Yoshi's House, or during the intro message, for instance.
Uses 7 bytes of free RAM. Use it as level ASM or use it in Game Mode 14 to apply to all levels.
Screenshot 1: Showing the timer itself. Screenshots 2, 3, and 4: Timer stops and changes palette when a goal tape is touched, a palace switch is hit, or when a boss is defeated. Screenshot 5: Timer freezes when animations and sprites are frozen. Screenshot 6 and 7: Timer does not show up during No Yoshi intros. Screenshot 8: When started from the midway point, the timer does not show up.
The main reasons for rejecting this are from poor optimization, overlooked errors, and the fact that the timer was displayed completely wrong upon insertion. Instead of starting at 0:00.00 like I would expect, the seconds was filled with complete garbage tiles and would increment all the way until it reached 0,1,2,etc.
As for optimizations and erros, the first problem comes from the unnecessary loading of the level number, $010B. After every branch, A is still the same value so you don't need to re-load it every single time. Also, you check against !NOTIME4 twice, forgetting !NOTIME5 entirely. This occurs both in init and main.
; and so on
Secondly, there's extensive use of CMP #$00, which is unnecessary if using BEQ immediately after loading the value. I'm only showing one case of it, but you might as well remove it everywhere that it shows up.
Lastly, I was thinking that since this is a speedrun clock, it should be as accurate to real time as possible. From comparing it to another timer I had going, it desynced fairly quickly. I'd recommend using NMI to get the timing accurate, since that runs exactly once per frame regardless of lag. Granted, this would require even further optimizations, but it's something to consider. Note that this point isn't necessarily reject worthy, but it would make sense to implement.