nesdev.com

That math looks off?

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

lidnariq: I will PM you with some information.

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!"

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

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

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

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.

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?

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.

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.

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.

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.

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.

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

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!"