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.

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.

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

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum