Recording request: NEC µPD7756C and the Mitsubishi M50805

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

lidnariq
Posts: 8785
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by lidnariq » Sun Jun 25, 2017 2:30 pm

That math looks off?
aerobics0-conversion-error-maybe.png
aerobics0-conversion-error-maybe.png (2.24 KiB) Viewed 7261 times
Shouldn't the waveform follow roughly where I've added it in red, rather than the weird flip?

User avatar
B00daW
Posts: 584
Joined: Thu Jan 03, 2008 1:48 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by B00daW » Sun Jun 25, 2017 2:33 pm

lidnariq: I will PM you with some information.

Lord Nightmare
Posts: 129
Joined: Wed Apr 05, 2006 10:12 am
Location: PA, USA
Contact:

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by Lord Nightmare » Sun Jun 25, 2017 11:00 pm

lidnariq wrote:That math looks off?
aerobics0-conversion-error-maybe.png
Shouldn't the waveform follow roughly where I've added it in red, rather than the weird flip?

This doesn't look quite right, I'll need to ask Sean about it later. Probably a sign got flipped somewhere...

LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"


User avatar
B00daW
Posts: 584
Joined: Thu Jan 03, 2008 1:48 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by B00daW » Mon Jun 26, 2017 5:41 pm

Thanks, Sean. I've attached the WAVs on the forum just in case. :)
Attachments
ft3as-wavs.zip
(Fixed) Family Trainer 3: Aerobics Studio
(59.69 KiB) Downloaded 362 times

lidnariq
Posts: 8785
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by lidnariq » Mon Jun 26, 2017 6:38 pm

It's really unfortunate that the original bipolar PWM DAC is clipping...

seanriddle
Posts: 12
Joined: Mon Jun 26, 2017 5:11 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by seanriddle » Sat Jul 01, 2017 12:25 pm

I've been busy with work, but had some time to do a little analysis on the captured data. Here's a link to my findings: http://www.seanriddle.com/m50805.txt

The logic to determine if the next frame will be a short frame is pretty contrived, so I'm going to double-check my conversion of the Logic capture to binary, and make sure there weren't any glitches that are confusing things.

I created a serial ROM in a CPLD and loaded it with the first sample. Using it, the M50805 in external memory mode output the same PWM as from the internal ROM. I haven't yet had the time to check the other 7 samples.

Any ideas for other tests? At some point I'll decap it and verify the 960 byte parameter ROM and dump the 312 byte decoding ROM.

User avatar
B00daW
Posts: 584
Joined: Thu Jan 03, 2008 1:48 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by B00daW » Sat Jul 01, 2017 1:22 pm

Hey, Sean... Awesome! It would be nice if Lord_Nightmare were to be able to supply you a simple, yet definitive, PARCOR stream to see if we can reproduce a custom tone or waveform. Are we able to do this without the decoder ROM codec?

seanriddle
Posts: 12
Joined: Mon Jun 26, 2017 5:11 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by seanriddle » Sat Jul 01, 2017 2:11 pm

I can feed in any bitstream and see what comes out. Pure trial and error would take a very long time since 2^47 is a big number, but I could change 1 bit of sample 0 at a time and see what that affects.

And the data dumped from TEST mode and the captured PWM output could be used to see if the format is similar to some other known format.

I've been wondering about what I've been calling the subframes; the (usually) 10 groups of bits that make up a frame. Maybe each one of those is a parameter; the data sheet mentions amplitude, pitch and K-parameters, but doesn't give any details. At first I thought they read in the bits in arbitrarily-sized chunks, but it makes more sense that they would clock in each parameter serially, then load it into its register. That gives us another hint, since we know the size of each subframe: 5, 7, 6, 6, 4, 4, 4, 4, 4, and 3 bits. Maybe that corresponds to some known format.

I'm not sure if I mentioned it before, but I shifted the samples left 1 bit in the WAVs that I created. The two 6-bit PWM outputs combined into a signed 7-bit format, so it made sense to shift that left for the WAV signed 8-bit format.

seanriddle
Posts: 12
Joined: Mon Jun 26, 2017 5:11 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by seanriddle » Sat Jul 01, 2017 3:05 pm

I found issues in the PARCOR dumps of sounds 4, 5 and 6 which likely caused the exceptions to the short frame logic. I was able to fix sound 4 by offsetting the start by one clock, but that didn't work for sounds 5 and 6. So I'm not sure if there was a timing glitch or some other problem. I'll check another dump and see if it matches.

Figuring out the clock pulse to start dumping the test bits was not trivial. The test pin is low before the first bit of the sample is output, and the sample could start with a 0 bit. So I had to make sure that my chosen start point didn't result in the test line changing before or after the DREQ pulses. I was off by one clock for sound 4, and it looks like there's some other issue with sounds 5 and 6.

User avatar
B00daW
Posts: 584
Joined: Thu Jan 03, 2008 1:48 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by B00daW » Sat Jul 01, 2017 3:23 pm

Before decapping, is the catalog number on the M50805 "058P" ? We should likely adhere to the naming scheme of m50805-058p.drom m50805-058p.prom for MESS.

seanriddle
Posts: 12
Joined: Mon Jun 26, 2017 5:11 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by seanriddle » Sat Jul 01, 2017 3:52 pm

I won't decap it until I confirm the parameter ROM dump and capture the PWM output when sending it some other data.

It is -058P, which I'm sure is the code for the ROM. It also has 705104, which might be a date code; 2 Toshiba chips are dated '86 and '87.

seanriddle
Posts: 12
Joined: Mon Jun 26, 2017 5:11 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by seanriddle » Sun Jul 02, 2017 11:21 am

I fixed the other sounds and that removed all the complications to the short frame logic. I updated the info in the file on my site. But when I programmed the CPLD with sounds 0-6 (sound 7 wouldn't fit in the CPLD I'm using), only the PWM for sounds 0 and 3 look identical to the internal ROM sounds. The others are similar, but not identical. I converted the PWM capture of my sound 1 to WAV, and it sounds the same. So if anyone is going to do any analysis on the PARCOR data, just use sounds 0 and 3 for now.

seanriddle
Posts: 12
Joined: Mon Jun 26, 2017 5:11 pm

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by seanriddle » Sun Jul 02, 2017 8:51 pm

I took the sound 0 data and inverted one bit of frame 0 at a time and captured the resulting waveforms (other than bit 5, which would have made the frame a short frame). This might be helpful in determining what each bit is for. I also did some tests with the first frame of sound 0 followed by 00000 frames and frames with bit 5 set. I think 00000 means repeat the previous frame. It's only used in the silent areas of sounds 6 and 7, but in my tests it didn't produce silence, so I assume it repeats the previous silent frame.

http://www.seanriddle.com/m50805sound0mods.7z
http://www.seanriddle.com/m50805tests.7z

Lord Nightmare
Posts: 129
Joined: Wed Apr 05, 2006 10:12 am
Location: PA, USA
Contact:

Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Post by Lord Nightmare » Sun Jul 02, 2017 10:45 pm

Wow, this is some seriously impressive work!

We know from the datasheet that this is LPC-8, not LPC-10, so that simplifies some things.

I'm guessing the frame rules are as such:
5,7,6,6,4,4,4,4,4,3 corresponds to energy, repeat+pitch, k1, k2, k3, k4, k5, k6, k7, k8
Technically the real layout is:
5,1,6,6,6,4,4,4,4,4,3 where the '1' is the repeat bit, and pitch is 6 bits long.
Hence:
00000 = "silence", but really: repeat last frame, unchanged. total frame length is 5
11111 = "stop", play silence for one frame and then terminate. total frame length is 5
else: continue pulling bits
next bit is 'repeat'.
0 = frame is not a repeat frame, pull 6+6+6+4+4+4+4+4+3 additional bits. total frame length is 47
1 = frame is a repeat frame, pull 6 additional bits. total frame length is 12

so valid frames for each type would be something like:
00000 = silence (or repeat...)
00001 0 101010 101010 101010 1010 1010 1010 1010 1010 101 = voiced/unvoiced "long frame"
00001 1 101010 = repeat with pitch change "short frame"
11111 = stop (end frame)

Now, unlike tms51xx and tms52xx chips, i suspect that both voiced and unvoiced frames are "long frames", so an unvoiced frame looks like:
01000 0 000000 011011 101100 0010 0110 0111 0100 0111 010
note the pitch is all zeroes, this probably switches it from using voiced energy source to PRNG-fed noise, as on the ti chips.
Also unlike the ti chips, the fact that all frames are long frames de-necessitates the messy (and buggy!) ZPAR logic to zero the remaining parameters, which is important on TI speech chips if you follow an unvoiced frame with a repeat frame which changes the pitch only!

LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"

Post Reply