openMSX
[Bug] Limit OPL4 I/O access [sf#547]
Reported by grauw on 2014-07-23 17:41 UTC Currently, the limits on accessing the I/O of the OPL4 are not emulated.
The limitations are described on page 8 of the application manual:
http://map.grauw.nl/resources/sound/yamaha_opl4.pdf
Address write: 56 cycles (FM) / 88 cycles (PCM) Data write: 56 cycles (FM) / 88 cycles (PCM)
Loading PCM header data requires a wait of approx 300 µs, see page 10 and 16.
Reading and writing external memory requires these waits, see page 16:
Data write: 28 cycles Data read: 38 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.
Commented by sd-snatcher on 2014-09-24 01:58 UTC It's important to mention that those cycles are related to this chip clock: 33.8688MHz.
Commented by grauw on 2015-03-07 00:20 UTC After a test with cycle-accurate timing on turboR, I have established that:
The required wait after an FM address write is 12 R800 clock cycles (6 3.58 MHz bus cycles, 56,77 OPL4 clocks).
The required wait after a PCM address write is 18 R800 clock cycles (9 3.58 MHz bus cycles, 85,16 OPL4 clocks).
Commented by grauw on 2015-03-07 00:30 UTC Regarding the discrepancy between the PCM wait (85.16 clocks vs. 88 clocks in the documentation), note that the R800 outputs the I/O data on the bus for 3 whole bus cycles (28,39 OPL4 clocks), so the OPL4 probably just catches on to the tail of the I/O signal.
A first step could be to add a callback for access to the chip that is too fast according to the specs. Then we don't have to reverse engineer the actual behaviour when this happens, and developers already get feedback about the too fast access.
Voting for a fix on this. I've started to program for OPL4 now. It seems like there are no limits on OPL4. This is a bit tricky to program for when you want to optimize and push the chip to the limits. Unless I am doing something wrong (???), it seems like the status for the chip being busy is always returning "not busy". This is from the status-port via IN A, (0xC4) and bit 0.
See https://github.com/openMSX/openMSX/blob/8544a076e6ba80605d31ae2176802a63d8c65b10/src/sound/MSXMoonSound.cc#L92
Op do 23 feb. 2023 12:42 schreef bengalack @.***>:
Voting for a fix on this. I've started to program for OPL4 now. It seems like there are no limits on OPL4. This is a bit tricky to program for when you want to optimize and push the chip to the limits. Unless I am doing something wrong (???), it seems like the status for the chip being busy is always returning "not busy". This is from the status-port via IN A, (0xC4) and bit 0.
— Reply to this email directly, view it on GitHub https://github.com/openMSX/openMSX/issues/938#issuecomment-1441617555, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWXCQLRGU2MQQEBBRNDSLWY5EMDANCNFSM4BJK7RVQ . You are receiving this because you commented.Message ID: @.***>
Thanks. It does seem like the comment isn't on the C4-port, though. But... I now realize that the wait cycles given are in OPL4-cycles, and the corresponding MSX cycles are very low. In fact, when in z80 mode it seems like the time to wait can be ignored if we measure the time between writes from the start of the first out command to the start of the next out command (a way to calculate which works for OPLL). The time to wait in OPL4 is less than the time of the OUT-command itself on the z80.