nesdev.com
http://forums.nesdev.com/

Recording request: NEC µPD7756C and the Mitsubishi M50805
http://forums.nesdev.com/viewtopic.php?f=6&t=16129
Page 2 of 3

Author:  lidnariq [ Sun Jun 25, 2017 2:30 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

That math looks off?
Attachment:
aerobics0-conversion-error-maybe.png
aerobics0-conversion-error-maybe.png [ 2.24 KiB | Viewed 868 times ]


Shouldn't the waveform follow roughly where I've added it in red, rather than the weird flip?

Author:  B00daW [ Sun Jun 25, 2017 2:33 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

lidnariq: I will PM you with some information.

Author:  Lord Nightmare [ Sun Jun 25, 2017 11:00 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

lidnariq wrote:
That math looks off?
Attachment:
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

Author:  seanriddle [ Mon Jun 26, 2017 5:25 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

d'oh, sorry about that. Stupid bug processing the negative DA1 samples. I replaced the files:

http://www.seanriddle.com/aerobics0.wav
http://www.seanriddle.com/aerobics1.wav
http://www.seanriddle.com/aerobics2.wav
http://www.seanriddle.com/aerobics3.wav
http://www.seanriddle.com/aerobics4.wav
http://www.seanriddle.com/aerobics5.wav
http://www.seanriddle.com/aerobics6.wav
http://www.seanriddle.com/aerobics7.wav

Sean

Author:  B00daW [ Mon Jun 26, 2017 5:41 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

Thanks, Sean. I've attached the WAVs on the forum just in case. :)

Attachments:
File comment: (Fixed) Family Trainer 3: Aerobics Studio
ft3as-wavs.zip [59.69 KiB]
Downloaded 29 times

Author:  lidnariq [ Mon Jun 26, 2017 6:38 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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

Author:  seanriddle [ Sat Jul 01, 2017 12:25 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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.

Author:  B00daW [ Sat Jul 01, 2017 1:22 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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?

Author:  seanriddle [ Sat Jul 01, 2017 2:11 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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.

Author:  seanriddle [ Sat Jul 01, 2017 3:05 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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.

Author:  B00daW [ Sat Jul 01, 2017 3:23 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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.

Author:  seanriddle [ Sat Jul 01, 2017 3:52 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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.

Author:  seanriddle [ Sun Jul 02, 2017 11:21 am ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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.

Author:  seanriddle [ Sun Jul 02, 2017 8:51 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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

Author:  Lord Nightmare [ Sun Jul 02, 2017 10:45 pm ]
Post subject:  Re: Recording request: NEC µPD7756C and the Mitsubishi M5080

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

Page 2 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/