Not a bug.... JR NC checks the carry flag, not what the C register contains... and LD_BYTES returns carry flag unset (NC) on error, so this is the error handling (JR NC) for an error within that CALL to LD_BYTES.
Documentation here:
https://skoolkid.github.io/rom/asm/0556.html
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! 🙂
