That explanation is good enough, I think, to understand the constraints and requirements, but I'd just like to note that it's not quite accurate as to the internal mechanisms. I could elaborate, but perhaps not here and now so as not to interrupt the conversation in progress.

As it's a ROM, you only need to worry about the arrival of data in time to the CPU. It might be interesting, then, to trigger off the clock and to monitor one or two data lines while the machine is doing something (if you can get it to do something) and see how late the data is changing before the clock edge, and how long it stays stable after the clock edge - as BDD implies, that's all the CPU cares about.

If you can run your scope for a while accumulating traces you should get a picture of the latest arrival and earliest departure.

The timings of the ROMs inputs (address, CS, OE) are the means to that end, of getting the ROM to respond in time to each read. Perhaps tracing one of those inputs, and one of the data lines, and triggering on the clock, would be useful.

Having said that, you don't want non-ROM accesses to turn up in these pictures, so you'd need to be running a test loop which only makes ROM accesses, for code and data.