Sorry - didn't spot this until just now.
I'll take a look at this asap.
EDIT: Just taken a quick look at this and it seems I'm not the only one to have this problem! I based my code on the programs given here:http://mdfs.net/Docs/Comp/BBC/SROM/Mastering/Module18
and the roms generated by this code have the same problem. Also, I had a look at JGH's BuildRFS fast ROM builder here:http://mdfs.net/Software/BBC/SROM/
and it has the same issue.
I've also looked at the example code given in the Advanced User Guide and can't see any differences with what I'm doing...
Looks like this is an issue with service call 13. The AUG says: Y contains "15 minus the ROM number of the next ROM to be scanned" and "If that adjusted ROM number is less than the number of the ROM receiving the call, the call should be ignored."
In all the code I've seen, including the AUG example, the value in Y is "adjusted" to the rom number by EORing with 15 and then the code does a compare with the rom number at &F4 and a BCC to implement the ignore.
Looking at it in the BeebEm debugger, the rom is first being sent service call 13 (&0D) with Y=0. Subsequently, it's repeatedly sent service call 13 with Y=16. This means that the first call is looking to scan rom #15 but the subsequent calls are looking to scan rom #-1.
I suspect this is an issue with the adjustment - doing EOR #15 is fine as long as rom 0 doesn't respond. If it does, I'm guessing that the OS decrements the next rom to be scanned and we end up in the Y=-1 situation. I'll modify my code to do SBC instead and see if that fixes it.