ADPCM: fixed address checking on read/write #38

hyano · 2022-07-06T16:23:22Z

We have changed the definition of at_end() and at_limit() in #33 (comment) .

So, we need to modify the address checking not only on clock(), but also on read()/write().
Please check this patch.

P.S.
I have resumed verification of real YM2608's ADPCM.
https://github.com/hyano/opna-analyze/blob/main/doc/OPNA.md
If I can find the internal behavior I will try to implement and send you another PR.

aaronsgiles · 2022-07-06T17:23:04Z

Wow, thanks for that great analysis! I'm currently reshuffling the code to align better with what you've discovered so far. Once I get it working, I'll update the code so that we can adjust it from there.

hyano · 2022-07-06T23:39:46Z

Thank you for your comment and seeing my memo even in Japanese.
This PR is just temporary fix for external behavior.

I'm happy that you will update the code with my analysis.
Please reject this PR whenever you like.

The charts and memos are summarized from signal and register value (with some guessing).
If you feel anything suspicious or unclear, please let me know. I'll revisit logs or add tests.

aaronsgiles · 2022-07-07T05:22:54Z

Do you have examples of systems/software that actually read or write data through the YM2608? (Or the YM2610?) I'd like to verify the reading and writing with live software if I can find some.

aaronsgiles · 2022-07-07T09:03:44Z

Ok, I have made my first attempt. Please see the branch adpcm-test.

Using a test program I seem to be matching your readings.

I am unsure of a few things, such as:

what does R10:$80 mean in your diagrams? (did you mean R00:$80?)
state of BRDY flag
behavior of writes to sample RAM (are there dummy writes like dummy reads?)
behavior relative to delta-N (does ADPCM state only change on overflow or is it more complex?)

You can try this code in your environment to see if it behaves the way you expect.

aaronsgiles · 2022-07-07T18:15:58Z

I just pushed an update to the branch that tries to fix some of the flag behaviors. Are these correct assumptions? (I'm guessing from your diagrams):

stop (reset) command does not clear EOS and does not clear PCMBusy
writing 0 to register 0 does not clear EOS either, but it does clear PCMBusy
starting a new playback (execute) clears EOS

This reverts commit b2baf00.

…hyano/opna-analyze/blob/main/doc/OPNA.md

hyano · 2022-07-09T06:01:22Z

I tried 0565762.
But it does not seem to work as expected with my environment.
Write and read(verify) data doesn't work. I'll check.

I extracted the register access sequence for testing with real chip.
https://github.com/hyano/opna-analyze/blob/main/test/metal_force_98.py
It contains the result by real chip. You can check it.
(bit.6 of status 1 is unknown and not deterministic.)

what does R10:$80 mean in your diagrams? (did you mean R00:$80?)

R10:$80 means write 0x80 to FLAG CONTROL REGISTER(0x10) to clear status (make all status flag to "0").

state of BRDY flag

I cannot check in detail because of my environment (slow to read status quickly).
So far I saw is:

BRDY is almost always "1".
"0" just after read/write register 0x08. (guessing from application manual)
BRDY does not become "1" during playback.
- Start playback by writing 0xA0 to register 0x00.
- Slear status (write 0x80 to register 0x10)
- BRDY looks keeping "0"

You can refer another analysis memo by KAJA.
http://www5.airnet.ne.jp/kajapon/brdy_eos.txt

behavior of writes to sample RAM (are there dummy writes like dummy reads?)

No dummy write like behavior.
MDEN is asserted just after write register 0x08.

I have logs and will create chart later.

behavior relative to delta-N (does ADPCM state only change on overflow or is it more complex?)

I can check and will try.

aaronsgiles · 2022-07-10T08:21:55Z

Ok thank you for the logs. I have made some updates.

It seems EOS and PLAYING flags are sticky until reset by the chip. There are 3 chips that use the ADPCM-B engine: YM2608, YM2610, and Y8950. I have changed the behavior so that the chips need to explicitly reset these flags.

See commit e2cd8df for a new update that matches your test behavior exactly, except for undocumented status flag 0x40, which I do not understand.

hyano · 2022-07-10T08:39:59Z

behavior relative to delta-N (does ADPCM state only change on overflow or is it more complex?)

I can check and will try.

I misunderstood your point as PCM outpu overflow.
I'll try if I can understand what kind of testing is required. Please tell me if you have.

However, I have created PCM overflow test and captured signals.
I noticed that somthing like 'clamp' happens during delta-N period.
YM2608 may have a separate ADPCM clamp mechanism before accumlating to mixed output.

Reference:

Test: https://github.com/hyano/opna-analyze/blob/main/test/adpcm_play_overflow.py
Logs: https://github.com/hyano/opna-analyze/tree/main/log/adpcm_play_overflow_mden
- _pcm.wav : PCM data output from YM2608
- _opt.wav : MDEN signal
- .bin.bz2 : raw signal from chip with CLOCK.

Is it OK to continue this kind of topic on this PR...?

aaronsgiles · 2022-07-10T08:52:55Z

Discussion on the PR is fine, or we can move to an issue instead if you prefer.

…set for all chips. Fix write case where start address is written after command

hyano · 2022-07-10T09:05:08Z

See commit e2cd8df for a new update that matches your test behavior exactly, except for undocumented status flag 0x40, which I do not understand.

It looks working fine. Thanks.
The external DRAM is detected as expected.
And ADPCM data transfer was also performed successfully.

hyano

I've read read/write related code and added some comments.

I have not checked the actual behavior with test code.
So, I'm sorry if I misunderstand the logic.

src/ymfm_adpcm.cpp

hyano · 2022-07-10T13:26:20Z

src/ymfm_adpcm.cpp

+
+				// otherwise, add two dummy samples
+				else
+					m_nibbles += 4;


2 dummy data are same as last sample at STOP ADDRESS.
It may be stored on REG08.

Maybe nobody cares...

Reference:
https://github.com/hyano/opna-analyze/blob/main/log/mem_rw5_mden/mem_rw5.txt#L24

READ ADDRESS 0fff-0xfff x 2
O10:00 O10:80 O00:20 O01:02 O02:FF O03:0F O04:FF O05:0F
RDF:48 RDF:48 <---- DUMMY READ
RA0:08 RA1:08 RA2:08 RA3:08 RA4:08 RA5:08 RA6:08 RA7:08
RA8:08 RA9:08 RAA:08 RAB:08 RAC:08 RAD:08 RAE:08 RAF:08
RB0:08 RB1:08 RB2:08 RB3:08 RB4:08 RB5:08 RB6:08 RB7:08
RB8:08 RB9:08 RBA:08 RBB:08 RBC:08 RBD:08 RBE:08 RBF:0C
RBF:08 RBF:08 <---- DUMMY READ
RA0:08 RA1:08 RA2:08 RA3:08 RA4:08 RA5:08 RA6:08 RA7:08
RA8:08 RA9:08 RAA:08 RAB:08 RAC:08 RAD:08 RAE:08 RAF:08
RB0:08 RB1:08 RB2:08 RB3:08 RB4:08 RB5:08 RB6:08 RB7:08
RB8:08 RB9:08 RBA:08 RBB:08 RBC:08 RBD:08 RBE:08 RBF:0C
O00:00 O10:80
O00:01 O00:00

Note:
Rxx:yy means read xx from REG08 and STATUS1 was yy.
STATUS1 is cleared after every Rxx:yy by writing 0x80 to REG10.

It was easy to do. I actually think it is not the byte from the stop address, but the last data that was processed.

src/ymfm_adpcm.cpp

hyano · 2022-07-10T14:05:24Z

src/ymfm_adpcm.cpp

 	}

 	// register 8 writes over the bus under some conditions
 	else if (regnum == 0x08)
 	{
 		// if writing from the CPU during execute, clear the ready flag
 		if (m_regs.execute() && !m_regs.record() && !m_regs.external())
-			m_status &= ~STATUS_BRDY;
+			set_reset_status(0, STATUS_BRDY);


I have not checked this behavior of BRDY.

What I confirmed was that
writing 0x80 into REG10 during playback clears BRDY status and it keeps "0" .
Maybe nobody cares...

BRDY is "1"

write 0xa0 to REG00 -- start playback

write 0x80 to REG10 -- BRDY becomes "0"

write 0xa1 to REG00 -- stop playback, BRDY keeps "0"

write 0x80 to REG10 -- BRDY keeps "0"

write 0x00 to REG00 -- BRDY becomes "1"

aaronsgiles · 2022-07-11T18:10:14Z

New commit on this branch makes all the tests in https://github.com/hyano/opna-analyze/blob/main/log/mem_rw_mden/mem_rw.txt match except for the first two dummy reads in "READ ADDRESS 0fff- CHANGE STOP" -- I do not understand why those would read $08.

hyano · 2022-07-16T06:37:31Z

except for the first two dummy reads in "READ ADDRESS 0fff- CHANGE STOP" -- I do not understand why those would read $08.

I checked where dummy read data came from.
https://github.com/hyano/opna-analyze/blob/main/test/mem_rw10.py
https://github.com/hyano/opna-analyze/blob/main/log/mem_rw10_mden/mem_rw10.txt
If the READ sequence is aborted, the data remains in m_buffer and would be seen in the next DUMMY READ.

Below are the results of the experiment with some parameters.

test for DUMMY READ after abort reading
- https://github.com/hyano/opna-analyze/blob/main/test/mem_rw13.py
- https://github.com/hyano/opna-analyze/blob/main/log/mem_rw13_mden/mem_rw13.txt
test for DUMMY READ after abort reading (REPEAT = 1)
- https://github.com/hyano/opna-analyze/blob/main/test/mem_rw14.py
- https://github.com/hyano/opna-analyze/blob/main/log/mem_rw14_mden/mem_rw14.txt

I also experimented with checking DUMMY READ after writing too much data with REPEAT=1.
(It is illegal usage and for analysis.)

test for DUMMY READ after writing (REPEAT = 1)
- https://github.com/hyano/opna-analyze/blob/main/test/mem_rw15.py
- https://github.com/hyano/opna-analyze/blob/main/log/mem_rw15_mden/mem_rw15.txt

After writing at STOP ADDRESS, it appears to switch to reading even if CPU is writing to REG $08.
Just after writing data at STOP ADDRESS, data on START ADDRESS seems to be loaded to buffer.
The last written data is seen on the top of m_buffer in the next DUMMY READ.
And the 2nd data of DUMMY READ seems to be the data in m_buffer which was read from memory.

aaronsgiles · 2022-07-18T23:28:06Z

Ok, if you grab the latest adpcm-test branch, it should produce matching results for all the cases you mention above. ade388d

I also checked in a C++ version of your rw13/14/15 tests that I used to test it out.

aaronsgiles · 2022-07-18T23:34:53Z

At this point, I have created a new PR for all this work: #40

Let's move any further discussion over there and close out this PR.

ADPCM: fixed address checking on read/write

b2baf00

hyano and others added 3 commits July 9, 2022 11:42

Revert "ADPCM: fixed address checking on read/write"

5b9f051

This reverts commit b2baf00.

First attempt to make ADPCM B match readings from https://github.com/…

75ad8e5

…hyano/opna-analyze/blob/main/doc/OPNA.md

Fix up flag states to more closely match analysis

e5c1a61

ADPCM-B flags for EOS and PLAYING are sticky; provide mechanism to re…

f23e97b

…set for all chips. Fix write case where start address is written after command

hyano commented Jul 10, 2022

View reviewed changes

Improve ADPCM read/write behavior to more closely match tests

c4b27aa

aaronsgiles 6D40 closed this Jul 18, 2022

aaronsgiles mentioned this pull request Jul 18, 2022

Improvements to ADPCM-B implementation #40

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

ADPCM: fixed address checking on read/write #38

ADPCM: fixed address checking on read/write #38

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ADPCM: fixed address checking on read/write #38

ADPCM: fixed address checking on read/write #38

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!