Unless the SampleClock output is being used as a interrupt on U501? But it shouldn't be necessary unless U501 would be unable to keep up with streaming the voice data; after all, it should be able to since it's the source. Wonder if the limitations of U502 required it to receive more attention in a more timely manner, and there needed to be some kind of feedback from it to U501 (via the SampleClock) to say "ready for next data NOW"?
Well, the complexity of the design and function are what original made some suspect the IC105 provided pass through functionality to the ADPCM chip. Especially since the ADPCM memory is port based, not flat model mapped to the IC901. The problem is dynamic, because you can set the playback speed. I.e. The time point where you need to switch the playback buffer (it's not split in hardware). I.e. The IC105 needs to know specifically the playback speed written to the ADPCM playback rate register. And other functionality that involves both. If that many address/bus lines are going from the 4bit rams to the IC501, then maybe the it's the chip providing the port+autoincrement of the ram as well (i.e. not flat mapped). It stands to reason. And bus read/write status too (accessing ADPCM memory is slow when playing samples at the same time. You have to poll the status reg, then immediately write when met). I still haven't looked over the M5205 datasheet to see what it
doesn't support/provide, and what other chip(s) are supplementing. Thanks for starting this thread. I think some misconceptions (at minimum on my part) will be corrected.
However, that seems strange given that the ADPCM clock is sourced by U501 in the first place; U501 should certainly know when it's done something....so it should know when it's time for the next sample without U502 asking for it.
Have you used a logic analyzer to see if the clock is fixed output (and at what speed) and/or relative to the speed register? That's definitely a bit of interesting new news. I need to probe some of these line with my scope, for my own curiosity.
Incidentally, U901 (HUC 6280), U902 (HUC 6270), and U903 (HUC 6280) are all custom ASIC's; the 6280 just happens to have an actual CPU core. It is not strictly correct to call it a CPU. The real CPU in the DUO is 501, the 91317.
I haven't seen anything that gives evidence that the D91317 is an MCU, let alone any sort of 'processor' core. ASIC has a pretty general meaning, but it's not in any way tied specifically to a processor or anything else. It's generally just a consolidation of other exiting logic/ICs into a single package. It's not like a GAL or PAL or a CPLD. The HuC6280 is definitely labeled as the CPU core and has the branding 6280 on it. Just because it has an included peripheral (audio) doesn't make anything less. Quite a few arcade boards use the HuC6280 strictly as an audio processor (and refer to the processor by such name), without ever touching/using the onboard audio circuit. The name of the chip has always equated to the processor. It's the other-way 'round. It's the audio unit that has no name. And to the programmer, they have no idea it's even on the same IC package as the CPU, since it's memory mapped port based - no embedded with special CPU only access register. PCFX took the existing audio IC and coupled it with a dual channel ADPCM chip and labeled it 'sound box'; that's the only time it ever got a name (other than loose/generic references to as PSG, PCMPSG, etc).
Some of chips might be considered an ASIC in the strictest sense, but they were original design packages. The HuC6260, HuC6270, and the HuC6280. The are the original chips of the PCE system with specific names (even official nick names; Tekkonon, 7up, Dr. Pepper). Nothing's changed of them in the consolidation into a single CD setup/system of the Duo. They are the core system chips and their names are respective and existing (and predominantly associative officially and unofficially). The D91317 is specifically an ASIC chip and in the context of the Duo, I don't think any other chip can be confused with that label. If anything, NEC could have saved money by consolidating the stock HuC6260 and HuC6270's. Hell, even the HuC6280. Sega ended up doing that for the late model Genesis systems (late model revisions in the model 2 Genesis/Megadrive systems).
I realize the IC105 isn't the only possible MCU in the CD system. Using that nick is an old habit from the RE/dev/emulation scene. On a programmer side, it's specifically just that (all the ports mapped and SCSI commands, etc); it's one of only two chips you are aware of (it and the ADPCM chip). Just a carry over on my part from the scene, as thee MCU. Using the designated IC ID number would be better, since you guys are getting confused.
Thus, the SampleClock input may actually be an interrupt function. (Just to make matters worse, U105 is an ASIC in design, even though it actually is a microprocessor, and U104 is an actual microcontroller! --AGGHHH!!)
IC104 in part of the CD low level hardware controller. So I never really paid much attention to it (since it's doesn't directly, AFAIK, interface with the CPU (6280)).
Hmm, if we continue to NOT have a standard naming convention here, our discussion will quickly become more of an effort to determine "which chip is he talking about", rather than actually making progress on the functionality of the system. Thus, your statement:
>>But I wasn't expecting to see ADPCM ram going to the ASIC<<
confused me. It doesn't go to the ASIC, it goes to the CPU (in my definitions), even though it's the same U501. Would it be acceptable to simply use the IC designators on these chips, rather than the chip numbers or their functions?
I agree. It avoids confusing if you know exactly what IC anyone is referring. But I wouldn't ever go as so far as to ever call the IC501 as thee "Duo" CPU. It's just interface logic, the glue to tie everything together. That label should specifically be the IC901 (not using the original/standard names is still a bit annoying).
Topic: DUO RAM (Read 526 times)
