#544 Limit OPLL I/O access


Currently, the limits on accessing the I/O of the OPLL are not emulated.

The limitations are described in Table II-2 on page 4 of the application manual:


Address write: 12 cycles
Data write: 84 cycles

These are quite specific numbers, but probably some further testing is required to confirm them, as well as the behaviour when access is too fast.


  • SD Snatcher

    SD Snatcher - 2014-09-23

    I'm all in for detailed emulation so developers can test their software using the emulator, but if you're going to implement this one and #545, #546 and #547, please also add an option to disable this I/O access speed limiter.

    Otherwise I won't be able to use openMSX to create turbofixes anymore.

  • Laurens Holst

    Laurens Holst - 2015-03-07

    After a test with cycle-accurate timing on turboR, I can confirm that the required wait after an address write is exactly 12 OPLL clock cycles.

    Last edit: Laurens Holst 2015-03-07
  • Laurens Holst

    Laurens Holst - 2015-03-07

    The data register wait timing is unfortunately much harder to pin down, it varies a lot and a quite sizable reduction in wait time will still only cause a few notes to be missed.

    One interesting find I did make however is that if you write too soon, the previous data write gets corrupted, rather than the new one.

    If I wrote a dummy value to a register (let’s say the TEST register) before the intended register write, there would be no audible effect even if I waited just 12 OPLL cycles (less than that started to cause problems). However if I do the dummy write after the intended register write, it would cause notes etc. to be missed, the frequency gradually decreasing as you get closer to the recommended 84 clocks wait. Actually I stop hearing missed notes well before getting to 84 clocks, around 75, but maybe they’re just too infrequent to notice.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks