I was wondering, does anyone own any of the following games? And would you be able to record audio of the various PCM samples found in them?
NEC µPD7755C (Jaleco)-Terao no Dosukoi Oozumou
NEC µPD7756C (Jaleco)-Moe Pro! '90: Kandou-hen
-Moe Pro!: Saikyou-hen
-Moero!! Pro Tennis
-Moero!! Pro Yakyuu
-Moero!! Pro Yakyuu '88: Kettei Ban
-Shin Moero!! Pro Yakyuu
Mitsubishi M50805 (Bandai)-Family Trainer 3: Aerobics Studio
(list from
here)
As I understand, these have expansion audio in the form of additional PCM (ADPCM?), supplied by the aforementioned chips. And they aren't supported in emulation. Having some audio recordings of them in action would be fantastic.
Well, for now you can check Youtube. There are some videos of hardware recordings.
M50805 is not entirely PCM. A colleague, hopefully, will be able to extract the PARCOR data in the coming weeks.
Another friend and I are in the process of attaching the 7756 and M50805 to a TNS* NSF cart that we will be programming custom NSFs for; which should control the audio outputs. He should be able to make recordings. Ultimately, we would like to have the data dumped.
We have some previous recordings of the various games. I don't even remember where in previous threads on the forum I'd found this, but I may as well attach it here now...
Attachment:
File comment: wav inside
jaleco d7756.7z [360.17 KiB]
Downloaded 337 times
To repeat what's been said in the past: if we change the clock of the µPD775x part, we should be able to get enough more data such that we can generate a perfect 9-bit back-translation of the DAC values. But this recording I found to be just a little too noisy for me to be confident I could calculate that exact values used in the DAC.
The datasheet for the part implies each recording inside the IC can choose between dividers of 80, 104 (edit1: determined from spectrogram of above recording), or 128 to generate the sample clock (640kHz→8, 6.2, or 5kHz). Although normal 44kHz sound card sampling "should" be enough, I'd really be happier with a larger amount of oversampling ... and ideally using a sampler that
doesn't have a highpass filter on its input.
(edit2:
MAME's implementation of the related µPD7759 thinks that waveforms in the ROM can pick sample rates that are any integer divisor of 160kHz, and change this rate at any arbitrary time, including in the middle of sample playback. They also say that divisors smaller than 9 might not work, and oddly enough say that the slowest divisor is 32 while they mention enough bits to support up the 64.)
B00daW wrote:
Well, for now you can check Youtube. There are some videos of hardware recordings.
M50805 is not entirely PCM. A colleague, hopefully, will be able to extract the PARCOR data in the coming weeks.
Another friend and I are in the process of attaching the 7756 and M50805 to a TNS* NSF cart that we will be programming custom NSFs for; which should control the audio outputs. He should be able to make recordings. Ultimately, we would like to have the data dumped.
That would be fantastic! Looking forward to your findings. Amazing work, and thank you for trying to shed light on this.
Here's the stuff I've found on youtube so far:
Family Trainer: Aerobics Studio-
https://www.youtube.com/watch?v=kgpRx_ypbxQMoero!! Pro Tennis-
https://www.youtube.com/watch?v=Eq-vzXZRVkcShin Moero!! Pro Yakyuu-
https://www.youtube.com/watch?v=gt_oV7F46XQThe rest seem to only have footage from emulation, at least that I could find.
lidnariq wrote:
We have some previous recordings of the various games. I don't even remember where in previous threads on the forum I'd found this, but I may as well attach it here now...
Attachment:
jaleco d7756.7z
Yes! Awesome, thank you.
B00daW wrote:
Another friend and I are in the process of attaching the 7756 and M50805 to a TNS* NSF cart that we will be programming custom NSFs for; which should control the audio outputs.
I just took a look at the JF-24A (SS88006 using) board and noticed that our previous documentation was at least partly wrong. These boards definitely connect CPU D7...D3 (and very likely D2) to µPD775x I5..I0
Given previous
muddied documentation it seems very likely that D1 and D0 are latched by the SS88006 and connected to µPD775x /START and /RESET respectively. But I can't verify this.
I feel it is somewhat debatable whether the discrete sound chips or the US versions playing of samples sounds clearer, but the sound effects for the Jaleco baseball and tennis games are much improved over their NES counterparts.
lidnariq wrote:
To repeat what's been said in the past: if we change the clock of the µPD775x part, we should be able to get enough more data such that we can generate a perfect 9-bit back-translation of the DAC values. But this recording I found to be just a little too noisy for me to be confident I could calculate that exact values used in the DAC.
The datasheet for the part implies each recording inside the IC can choose between dividers of 80, 104 (edit: determined from spectrogram of above recording), or 128 to generate the sample clock (640kHz→8, 6.2, or 5kHz). Although normal 44kHz sound card sampling "should" be enough, I'd really be happier with a larger amount of oversampling ... and ideally using a sampler that doesn't have a highpass filter on its input.
According to the datasheet, the sample data could just be dumped with "verify" mode too if the chip were pulled, eh?
No
The parts other than the µPD77P56 lack the required pins.
Oh, YES! I remember reading that. I guess I'll talk to ImATrackMan to see if he can lower the clock of some of the 7756 cart I gave him so he can record some sample data for you; if you're up to the task of converting it to 9-bit?
I'm certainly up for giving it a shot. I don't know how much head room below the nominal 640kHz will be useful—obviously it's partially a function of the sample rate and highpass/lowpass corners of the recording sound card also.
The fun bit is gonna be unboiling the egg and turning the recovered 12?-bit pcm data back into the 4-bit-per-sample source adpcm data from the 7756c mask rom. That's actually possibly doable, since theres only 16 possibilities per sample and you can do analysis-by-synthesis to find best fit for each one.
Or someone could donate 7756 carts for decap, sean riddle has been doing some amazing stuff with game&watch game MCUs recently, so it might be possible to optically read 7756 rom, unless they used implant rom for it...
LN
EDIT: But that m50805 REALLY interests me as well, that's i believe in the same series of LPC/PARCOR chips as used by the original "talking" version of nintendo's arcade game "radar scope".
I'd honestly love to see one of those chips decapped so I can make sure the LPC tables in mame are correct, for synthesis.
One of the random things I find interesting is that the implementation of the µPD7759 in MAME only mentions the 4bit-per-sample ADPCM.
And yet, the datasheet for the µPD775[5-8] says "bit rates from 10kbit/s to 32kbit/s", implying that there's a 2bit/sample ADPCM mode... At least, I think they're implying that instead of just referring to repeat mode. They do explicitly call out silence padding separately.
MAME's µPD7759 implementation also implies a wide range of possible sample rates, ranging anywhere from 160kHz down to 2.5kHz (I think? Assuming
640kHz÷4÷(F+1)), and can switch during in the middle of playback.
Lord Nightmare: The person in question also has the cart. If you wish to contact him, he may be able to help. I'm not concerned with the state of return of the cart; as long as it's dumped and emulatable.
With some redaction, here are the WAV files dumped from the chip by Sean and some information:
"It works as described in the datasheet; every 64 clocks (100uS at 640kHz), DA0 or DA1 goes low for 0 to 63 clocks. I exported the dump and combined the two PWM signals for each sound into a single 7-bit signed file, then used Audacity to convert those into WAV format:"
We're still in the process of troubleshooting and finding methods to find the encoded data.
Removed the attachment so that bad files are not distributed.
That math looks off?
Attachment:
aerobics0-conversion-error-maybe.png [ 2.24 KiB | Viewed 6388 times ]
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.
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
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.txtThe 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.7zhttp://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
I found another Aerobics cart for $12, so I bought it and decapped the chip in the one B00daW sent me:
http://seanriddledecap.blogspot.com/201 ... -post.htmlThe 312-byte decoding ROM is easy to spot, but unfortunately the 960-byte parameter ROM seems to be implant ROM, so I can't see any of the bits.
I needed a primer on PARCOR/LPC, and Cater's Electronically Speaking has a good introduction:
http://www.seanriddle.com/lpc.pdfAs Lord Nightmare said, this looks a lot like TI's LPC.
So the decoder ROM is in the middle left and the parameter ROM is on top?
Yep. The decoding ROM bits are easy to discern, although I haven't tried figuring out the layout. I can't see any bits in the parameter ROM.
The top left pad is pin 4, numbered counter-clockwise. It's easy to spot the power inputs and the huge drivers on DA0 and DA1. The 2 pads in the lower right aren't connected to anything. There's an extra pad, so I assume the 22-pin and 24-pin versions use the same die, but clock output isn't pinned out in the 22-pin version.
I put more info here:
www.seanriddle.com/m50805.html
sean, can you take a hi-res image of the smaller, visible rom area? I should be able to get the lpc tables extracted, but I need more zoom.
LN
And here's the decoding ROM with the top metal removed:
http://www.seanriddle.com/m50805aciddecodingrom.jpg
So looks like we could read the decoder ROM to assemble a binary from it... What do you think the next logical steps for the parameter ROM should be? Lord Nightmare?
The 960 byte rom may require etch/staining, which is outside my realm of expertise
However it is likely we have the entire contents of it anyway from the data line traces?
LN
Is there any program made that can analyze a decap picture through filters and bitmap (with proper image setup and formatting) to create a dump?
I'm not sure what I'm looking at regarding which is a 0 and which is a 1 regarding the decoding ROM decap...