Please see the full screenshot. The first JR NC is not relevant (it was in red due to a breakpoint I put on my ZEsarUX emulator). See the LD A,C just some opcodes below that ;)
looking at that code, I don't see any use of the C register before calling the rom load routine (and you would also need a push/pop probably). C register on return from the rom load call is undefined (usually value 01, 0x21 and others) but it doesn't tell anything relevant (I think it's the last value sent to the port feh to draw the border stripes). So I think that's a bug in your code ;) Some emulators like Fuse return C=01, others like mine (ZEsarUX) didn't return anything on C register, so the game was failing and that's the reason I started debugging it, hehehe. Now I'm returning C=01 and yours is the only game that failed loading (of course this is the "fast load" tape method, if I do a "slow" load (realtime) it was working. I assume your game doesn't load on other emulators either
OK, so I think I've figured out the issue here... the section below your breakpoint (red line) is supposed to check the filename in the header... check 10 characters (LD B, $0A) and JR to tl_header (JR NZ, $A14B) if any characters don't match.
The highlighted LD A, C should really be LD A, B - however we already know that B=0 after the final DJNZ, making this extra check redundant!
I will test and release an update once I'm confident that this is the issue... it is likely replicated in the main code loader so I'll need to fix there too.
Thank you for efforts and bug report! 🙂