Jaleco games with D7765C ADPCM decoders.

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Jaleco games with D7765C ADPCM decoders.
by B00daW on 2012-09-16 (#99719)
BootGod's database has a nice list of which games have the NEC D7765C ADPCM decoder.

When checking these out and doing a little more research, it dawned on me that there will not be a "good dump" of any of these games until the D7765C chips themselves are decapped and the ADPCM data can be attached as a footer to the ROM images. Emulators could then access the sound data directly instead of relying on WAV playback and external files.
Re: Jaleco games with D7765C ADPCM decoders.
by lidnariq on 2012-09-17 (#99724)
This has come up before:
viewtopic.php?t=762
viewtopic.php?t=4030

TL,DR: Given a cartridge it should be possible to slow down the clock from the rated 640kHz and record with enough precision to exactly recreate the 9-bit PCM output stage of the chip. Recreating the underlying ADPCM is an optional additional exercise.


P.S. I kinda want a NSF-equivalent song composed that actually uses the ADPCM hardware.
Re: Jaleco games with D7765C ADPCM decoders.
by B00daW on 2012-09-17 (#99732)
lidnariq wrote:
Given a cartridge it should be possible to slow down the clock from the rated 640kHz and record with enough precision to exactly recreate the 9-bit PCM output stage of the chip. Recreating the underlying ADPCM is an optional additional exercise.

P.S. I kinda want a NSF-equivalent song composed that actually uses the ADPCM hardware.

I read the those posts you're speaking about from the Wiki.

Well, I think all we need to do is dump the numbers 220, 186, and 148. I don't think it makes sense to me to just rip and record the WAV files. We could have the ADPCM files directly in the NES ROM to be accessible by the $7000-7FFF register.

Regarding an NSF, I thought it would be kind of cute if we decapped and dumped the three chips that we could make NSFs given the existing samples in a special JF+D7765C NSF driver. :) I know we would have to specify another expansion chip number, but it would be in the same vein and "accurate." Also, I think the Japanese would have fun making their own songs with these samples as well. :)

Edit: I've made a few more implications regarding the music composition area in the FamiTracker forums.
Re: Jaleco games with D7765C ADPCM decoders.
by zzo38 on 2012-09-17 (#99745)
I have added this to DotFami. Currently, it specifies that the ADPCM samples are only available in ROM (although this ROM needs not be mapped to the CPU), and cannot be RAM. DotFami does require the audio data to be included in the ROM area of the .fami file.

For UNIF, you could add an extra chunk for this audio data, and for NES 2.0, I don't know.
Re: Jaleco games with D7765C ADPCM decoders.
by lidnariq on 2012-09-17 (#99750)
B00daW wrote:
Well, I think all we need to do is dump the numbers 220, 186, and 148.
Where did these numbers come from?
Quote:
I don't think it makes sense to me to just rip and record the WAV files. We could have the ADPCM files directly in the NES ROM to be accessible by the $7000-7FFF register.
The point is that we don't need to decap the ICs to read the ROM contents; we can actually reconstruct the exact original data by observation. We know all of the recorded sounds are 5, 6, or 8kHz 9-bit audio that can be compacted into (most likely) 3 bits per sample. As a result, given a 96kHz 16-bit recording, possibly after having underclocked the IC in the first place, we should be able to figure out the original compression specifics and generate the original 3 bit data stream.
Re: Jaleco games with D7765C ADPCM decoders.
by B00daW on 2012-09-17 (#99757)
The numbers are from BootGod's page in my original post. Check the PCB scans and chip listings. I assume that these are three specific ICs with the custom samples that NEC's factory wrote and produced for them.

Would it really be exact? Sounds like taking an MP3 at a specific bitrate, decoding to WAV, then encoding it back to the same bitrate again.

I know The Guru does IC decapping but his list is seriously backed up for what he wants to accomplish. I may consider your option.
Re: Jaleco games with D7765C ADPCM decoders.
by tepples on 2012-09-17 (#99760)
MP3 round-tripping is complicated by the fact that MP3 uses overlapping blocks for its cosine transform, causing rounding errors to propagate to samples in the previous and next blocks. ADPCM, on the other hand, is a simple deterministic algorithm, and rounding errors propagate no further than the next sample. Even JPEG can be decompressed and recompressed, as rounding errors don't propagate outside one 16x16 pixel macroblock.
Re: Jaleco games with D7765C ADPCM decoders.
by lidnariq on 2012-09-17 (#99761)
B00daW wrote:
The numbers are from BootGod's page in my original post. Check the PCB scans and chip listings.
Oh, they're product or data loadout numbers.

Quote:
Would it really be exact? Sounds like taking an MP3 at a specific bitrate, decoding to WAV, then encoding it back to the same bitrate again.
ADPCM is stricter enough—especially 3-bit ADPCM—that the question of "what was the original encoding this could possibly have been?" is a lot more straight-forward. More akin to "given a WAV of a MIDI, reconstruct the original MIDI" than MP3.
Re: Jaleco games with D7765C ADPCM decoders.
by rainwarrior on 2012-09-17 (#99763)
It would be relatively easy to support in NSF software players. For something like PowerPak it might be out of the question due to the additional ROM requirement.

If you can successfully reverse engineer the ADPCM format, I'd be willing to support it in NSFPlay. (I'm not really interested in supporting a list-of-WAV-files kinda thing.) There is room for another expansion bit in NSF, and it would be easy to put the data at the end of the ROM area.

Some reasons not to bother, maybe:

1. None of these games used the samples for music.
2. The samples seemed to be overpoweringly loud.
3. When ported to the NES, these games used DPCM or PCM samples (haven't checked which).
4. Custom samples in hardware is going to be very difficult to accomplish.

Those reasons don't really matter to me, but not knowing the ADPCM format does.
Re: Jaleco games with D7765C ADPCM decoders.
by rainwarrior on 2012-09-17 (#99764)
The datasheet describes how to read the chip data: http://bootgod.dyndns.org:7777/downloads/UPD7755_UPD7756_UPD7757_UPD7758.pdf

It is described in the PROM section of the datasheet, but presumably it could work for ROM versions?

A chip's ROM dump and corresponding WAV output, along with some notes on how the game executes them, should probably be enough to reverse engineer the ADPCM format details. There probably isn't a need to decap the chip itself (unless you wanna).
Re: Jaleco games with D7765C ADPCM decoders.
by B00daW on 2012-09-17 (#99765)
We just have to read the RAW data out of those ICs some how. Not sure why decapping would be absolutely necessary. We can read them from the data pins, right?

BootGod still might have all the carts that he's dumped.
Re: Jaleco games with D7765C ADPCM decoders.
by lidnariq on 2012-09-17 (#99767)
The ROM versions don't have the MD0…MD3 or Vpp pins needed for readout.
Re: Jaleco games with D7765C ADPCM decoders.
by rainwarrior on 2012-09-17 (#99770)
Aw, I didn't notice the non-PROM pinout diagram on the previous page. :(
Re: Jaleco games with D7765C ADPCM decoders.
by B00daW on 2012-09-18 (#99811)
Well, certain arcade games use the D77P56. If someone dumps that we can understand the encoding then record and encode the other samples.
Re: Jaleco games with D7765C ADPCM decoders.
by 80sFREAK on 2012-09-18 (#99819)
Main reason not to bother - all these chips contain mask-ROM preprogrammed sound samples, mainly noise of stadium or so. Three digit numbers on the part is related to "built-in" sound samples. End of story.
Re: Jaleco games with D7765C ADPCM decoders.
by B00daW on 2012-09-19 (#99851)
Like I said, the P variety was user-programmable. Certain arcade machines used it. Luckily for us hap has recently dumped one for Ganbare Jajamaru Saisho wa Goo / Ganbare Jajamaru Hop Step & Jump on one of the newer MAME SVN releases.

http://mamedev.org/source/src/mame/driv ... run.c.html

MAMEdev wrote:
467 ROM_START( ganjaja )
468 ROM_REGION( 0x30000, "maincpu", 0 )
469 ROM_LOAD( "1.ic43", 0x00000, 0x04000, CRC(dad57543) SHA1(dbd8b5cee33756ee5e3c41bf84c0f7141d3466dc) )
470 ROM_CONTINUE( 0x10000, 0x1c000)
471
472 ROM_REGION( 0x10000, "gfx1", 0 )
473 ROM_LOAD( "ic60", 0x00000, 0x10000, CRC(855f6b28) SHA1(386411e88cf9bed54fe2073f0828d579cb1d04ee) )
474
475 ROM_REGION( 0x20000, "gfx2", 0 )
476 ROM_LOAD( "2.ic120", 0x00000, 0x20000, CRC(e65d4d57) SHA1(2ec9e5bdaa94b808573313b6eca657d798004b53) )
477
478 ROM_REGION( 0x08000, "d7756", 0 )
479 ROM_LOAD( "d77p56cr.ic98", 0x00000, 0x08000, CRC(06a234ac) SHA1(b4ceff3f9f78551cf4a085642e162e33b266f067) ) /* D77P56CR OTP rom (One-Time Programmable, note the extra P) */
480 ROM_END

If we can obtain a copy of ganjaja.zip and rainwarrior looks at d77p56cr.ic98 he could potentially figure out the ADPCM format. Otherwise just looking at UDP7759.C should yield answers.

http://mamedev.org/source/src/emu/sound/upd7759.c