DUO RAM

[Charlie]

As per a members request, here is some data on the DUO RAM system:



(Note U515 pin 24 --- still working on it)

Charlie

Edit 6/16
Edit 6/17

[thesteve]

i really need more info on U105.
from what i could see U106 is acting as a cd data cache by U105.
U105 takes serial data from the cd and directs it several places, including the main data bus.
i have one here that is not sending data from U106 to the data bus.
U106 is being written from the cd

[Charlie]

Since U106 is a standard SRAM, I can certainly get the address and data buss info between it and U105, as well as CE*, WR*, etc.  I believe the data comes into U105 on pin 86?

However, U105 does a lot more than talk to U106, it's the main ASIC supporting U501, the '91317 CPU.  Hope the address/data info will be sufficient.

Charlie

[Charlie]

Here is U106 interaction with U105



Good luck

Charlie

Edit 6/16

[thesteve]

how about U105 and U501 interaction
i believe U105 contains a bus switch function, that is not getting enabled.
the function is to read U106 onto another data bus.

[TurboXray]

904 and 905 are SRAM chips (32kx8bit) paired to make video ram for the VDC. My Duo has them listed as IC904/IC905.

IC906 (U906 on your layout), is 8kx8bit SRAM (PCE 'work' ram, available for hucards and CD games). This is mapped to bank bank $f8 (and should be mirrored to banks $f9-$fb or external 6280 address bus range 0x1F0000-0x1F7FFF ). I'm assuming the giant ASIC has all the glue logic to handle enabling and disabling the bios ROM (mirrored as 512k) and the CD ram. The SuperCD ram is 256k total and IC515 & IC514 make this up. But when a hucard is inserted, the detect pin on the port tells the ASIC (IC501) to direct all lower 1Mbyte range to hucard port. The funky thing is, is that 64k of that 256k (or rather one of the 128k chips) still needs to be mapped right above that 1Mbyte range. I.e. the mapping isn't clean as you think it would normally be. But hey, you got a giant ASIC to handle it all so who cares ;)

 IC106 is the work ram for IC105. IC105 is the custom MCU that the PCE interfaces with to send SCSI type packets to and also receive status of the CD unit (mapped only as ports in $18xx range of bank $ff). It's believed that the MCU also controls the M5205 (IC502) and provides the interface for the CPU to the ADPCM playback chip. The IC105 provides the interrupt too, when streaming CD data to the ADPCM ram (interrupts the CPU when 32k of the 64k ADPCM RAM has been 'played' so the software can switch the ADPCM memory pointer to the alt buffer). Anyway, it's unknown how many sectors are buffered (read ahead). But at minimum at least one sector is buffered and stored in IC106 (well, data sector is 2048k + sub channel data (96 bytes IIRC), and 300+ something error correction bytes. But you only have access to sector data (be it CDDA via a special port, or CD data ) and the Sub channel bytes, via the MCU/IC105). Rom is internal to the IC105 and IC106 provides the work ram. I don't think I have the datasheet or info on the D6378 (IC105) anymore, so this is from memory.

 IC512 is the only 2k sram chip on the system that I could find, that leaves pretty much only one possibility: BRAM. Hardware bank $f7 (though the address lines are NOT mirrored up into the 8k bank range). It's too far away from the CD IC logic/chip area and is pretty much right under the ASIC on the flip side. Makes it a perfectly reasonable assumption.

 IC515 is definitely the bios ROM chip. But I can't find a data sheet on the NEC part number. The closest I got was for UMC for the UM23C4001 CMOS mask-rom chip.


 Hope any of this info helps.

[thesteve]

that helps some by confirming what i had figured out regarding IC105.
what i found regarding IC106 is, during non cd play the data bits are active, but the addressing is not.
once the cd reads the chip starts addressing the ram.
on the unit with the prob the IC106 data lines are only active during cd read.

what i need is pin info on IC105, to determine if its data is being requested.
either the data request isn't making it to the chip or the chip is bad

[Charlie]

I may have some of the actual RAM usages/names mixed up, but I am fairly sure of the interconnects.

Here's some notes that may fill in the blanks of your data:
1. 502 comms with 501, who in turn comms with 105.
Here's 502 pin data:
a) Voice data VD0-VD4 on pins 4-7 respectively
b) VCK, VRST, VXT on pins 14, 15, 16 respectively
c) ADPCM out pin 10

Here's 501 pin data:
a) Voice data VD0-VD4 (to U502 ADPCM) on pins 89-86 respectively
b) VCK, VRTS, VXT (to U502 ADPCM) on pins 82, 92, 93 respectively
c) CD data in/out on pin 86 (?)
d) CD LRCK on pin 88
e) CD CLK on  pin 90 (?)

2. Using the 23C4001 data for 515 is close enough -- you can use the pin data of 515 in my diagram to pick up the minor pin differences.

3. 105 is shown in part in my diagram, you have the address buss and data bus, and some supporting lines.  What you need, I think, is the interconnect between 105 and 501.  I can give you this additional 105 data:
a) RST on pins 49 & 99 (tied together) connect to U104 pin 22 (Reset)
b) pins 3-10 are connected to U104 pins 56-49 (port D) respectively (8 lines)
c) pins 17-12 are connected to U104 pins 41-46  (port F) respectively (6 lines)
d) pins 94-96 are connected to U104 pins 59-61 (port A) respectively (3 lines)
e) pins 38, 39, 41-46 are connected to 501 pins 103-96 respectively (8 lines)
f) pins 56, 32, 33, 35 (tied to 54), 55 and 57 are connected to 501 pins 119, 118, 115, 117, 116, 114 respectively (6 lines)
g) pins 18-20 are ALE, WR*, RD* to U104  pins 40-38 (ALE, WR*, RD*)respectively
h) pin 93 drives transistor 105, which connects to 104 pin 14 (port C)

I do not think it is a coincidence that items B and E, and items C and F, have the same number of lines.  It is likely that the same data is being transferred between those three IC's.
Note that U104 data is available on the 'net.

I will clean up my diagrams in the near future, after we agree on the final data.

Charlie

Edit 6/16
Edit 6/17

[thesteve]

that looks promising.
I will confirm when i get a chance.

PS did i buy a PC-FX from you? (I responded too late to a second chance offer, but bought it anyway)

[Charlie]

No, haven't yet sold anything.  But I am getting ready to sell some CD systems on ebay, as soon as I get around to taking the pictures, etc.

[Charlie]

Schematics updated, text edited 6/16.

Charlie

[TurboXray]

IC510/IC509 are 4bit rams for the M5205 ADPCM playback chip (IC502), but they're accessed as a single 8bit read/write by the CPU. A quick look, looks like both the M5205 and both ram chips tie into the ASIC, on my Duo. Can you verify this? If so, it looks like the MCU (IC105) isn't needed for the interface to the ADPCM chip (and that the ADPCM is actually generating the IRQ needed for streaming, I need the look over the data sheet and see ).

[Charlie]

>>IC510/IC509 are 4bit rams for the M5205 ADPCM playback chip (IC502), but they're accessed as a single 8bit read/write by the CPU<<
Agreed, realizing that the CPU is U501

>>both the M5205 and both ram chips tie into the ASIC<<
The ram chips tie only into the CPU.  Is that what you meant when you said ASIC? If so, then agreed.  I indicate the M5205 connections in reply #7, under "501 pin data".  

>>the ADPCM is actually generating the IRQ <<
Confused on this one.  There is no IRQ type pin/connection on U502.  There is only the VoiceDdata (4 lines), Clock in, SampleClock out, and Reset.  Not to mention that there is no need for a chip of this type to do anything with interrupts anyway.

Should I add U502 to the schematic, or is the text sufficient?

Charlie
 
PS: Did no one realize I spelled "bidirectional" incorrectly???  Edited on 6/17

[TurboXray]

>>IC510/IC509 are 4bit rams for the M5205 ADPCM playback chip (IC502), but they're accessed as a single 8bit read/write by the CPU<<
Agreed, realizing that the CPU is U501

The ASIC is IC501. The CPU is IC901. The ASIC maps all the required devices into a neatly fit into the 2megabyte external address range of the actual CPU (IC901). So it's just a giant glue logic interface chip for address mapping (switching, no need for realtime bus arbitration in this setup). But I wasn't expecting to see ADPCM ram going to the ASIC. That's very interesting

>>both the M5205 and both ram chips tie into the ASIC<<
The ram chips tie only into the CPU.  Is that what you meant when you said ASIC? If so, then agreed.  I indicate the M5205 connections in reply #7, under "501 pin data".

Well, looking how the ADPCM chip is mapped to the CPU address, it's mapped as ports for the ADPCM 'registers', but memory is not mapped as flat. It's mapped as a data read/write port. AFIAK, the M5205 didn't provide its own memory as to another device via read/write port. Also, the 4bit memory appears to have some pins going to the ASIC - which doesn't queue up how you access the device directly. But there's a DMA mode, where the MCU (IC105, which the CPU/6280 talks to all the time) will transfer data from a sector + length to the ADPCM ram via a special mode that requires no CPU intervention or manual copying. That mode also extends into "streaming" sector data from the CD to the ADPCM memory without CPU intervention as well (continuous DMA), but it requires what you responded to below...

>>the ADPCM is actually generating the IRQ <<
Confused on this one.  There is no IRQ type pin/connection on U502.  There is only the VoiceDdata (4 lines), Clock in, SampleClock out, and Reset.  Not to mention that there is no need for a chip of this type to do anything with interrupts anyway.

Ok, then the interrupt must be coming from the MCU then (IC105) (since it's streaming the data from the CD directly to the ADPCM ram). The interrupt is generated when 32k of the ADPCM memory has been played and the ADPCM pointer is ready to be switch to the alt buffer (the other 32k. I.e. double buffering the 64kx8 as two 32kx8 segments). Not sure why it needs the CPU to do this, but it does. Else, if IRQs or IRQ mask for BRK are disabled then you only get 32k worth of sample stream request to playback(found that out the hard way). AFAIK, the ASIC was new to the Duo models from what others have said in the past. But I haven't actually looked at the original CD rom unit layout. If it's different, that'll explain some functionality packed into the ASIC (a consolidation of other support chips/logic). I have one for the PCE, I'll open it up and have a look.

[Charlie]

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"?  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.

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. 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!!)

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?

Charlie

PS: Had a thought --  maybe I'll make up a flow chart of interconnections via buss, rather than individual pins.

[thesteve]

yes please refer to the chips per designator, as the duo has multiple micro-controllers, processors, specialized processors ect.
a data flow chart could prove quite useful.
any pin data on the custom chips would be helpful, especially as it refers to usage

[TurboXray]

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).

[Charlie]

Well, I don't want to tie up this thread with a name/type discussion; the intent is to help with the ram usage.  Just a note that I didn't say "the D91317 is an MCU", I said it is a CPU.  U104 is an MCU.

>>Have you used a logic analyzer ...<<
No, I don't have any specific reason to do so.  I don't need that depth of analysis for the typcial repairs.

I'll update the schematics with data busses in the future.

Charlie

[Charlie]

Sorry, guys, but the "data flow chart" is going to have to wait.  After I dug deeper into the system, I realized that it will probably take about 4 sheets to show the entire path from the laser into memory in enough detail to be useful; not something I can do in just a few days!  It would help if you could narrow it down a bit!

As an FYI, I went back to the manf's data again, and the tech specs on the DUO (dated 1993):

1. U105 is listed as "U105 uPD6378 ASIC".  It got classified by the tech data as an ASIC ("Application Specific Integrated Circuit") because of it's "application specific" status; it would be more correctly identified as an ASSP ("Application Specific Standard Product") which is how the IC manufacture classified it.  It is, by manufacturers definition, a CR ROM Drive Controller.  It has the following characteristics:
a) Error correction function on chip
b) Error correction repeatable 3 times(real-time)
c) Double-speed replay capability
I also strongly believe it has SCSI capability.

2. U501 is listed as "U501 uPD91317 CPU".  It is a custom ASIC (as classified by the manufacturer) with the following characteristics (as per the data sheet):
a) High integration: 17k gates
b) Accepts MEGA macro and ANALOG macro blocks
c) Accepts RAM up to 64k bits
d) Survives latch-up currents over 1A
e) Power consumption: 15uw/MHz/cell
f) Ram access time 25ns for 256x8


Charlie

[TurboXray]

Not sure if this helps your cause, but here is the info for the original CD base + CDROM unit.

http://www.pcedev.net/PCE_chips/IFU-30/

 The base only holds the giant ASIC (just like the one in the Duo). Again, ADPCM functionality is completely handled by this chip to interface to the systems processor (6280). It doesn't the functionality of the Duo's bus switching logic since it doesn't have direct control/interface of the hucard port. The CD deck also holds the 64k of CDROM (two 32kx8bit 70ns SRAM, instead of the two 128ks of the Duo since it's not SuperCDROM ram) and 2kx8bit 150ns SRAM for BRAM (150ns is just slightly too slow for the CPU to access it in normal mode, thus why the system card puts it in slow 1.79mhz mode to access this). All three ram ICs are on a daughter board, though that doesn't really have any relevance in comparing to the Duo.

CD interface deck:
D91061GD (custom ASIC)
M5205 (ADPCM controller)
M5M5256BFP-70 x2 (64k CDRAM)
LC3517BML-15 x1 (2k BRAM)
M5M4464AP-12 x2 (ADPCM ram. 64kx4bit DRAM x2)
Some misc stock 74x series logic for bus transmission (mostly 245's)
1x CDROM inteface port


CDROM unit itself:
D4364Q-12L (surface mount ram)
D6378GF
D78C14GF
CXD11167Q
CXA1082BQ
CXA1081M

I also strongly believe it has SCSI capability.

It's pretty close from what I've been told. I haven't worked with low level scsi packet interfacing before but from what I've read on it (indirectly through researching ATAPI scsi type replication), the command string structure looks like scsi from looking at the system card debugging/tracing and custom interface routines of later games.

[Charlie]

Cool pix!  Thanks!  Never opened the IFU (don't think I have the docs on it, just the DUO), but it make sense that the DUO and the CD/IFU would use very similar circuitry, right down to probably the same chips in most/all cases ('1167, '1082).

Charlie

[thesteve]

https://www.pcengine-fx.com/forums/index.php?topic=16503.msg342958#msg342958
started a thread on identifying the pinouts/functions of the cd related circuits

[Fidde_se]

The IFU-30 (Briefcase) Full Component Guide might help too https://www.pcengine-fx.com/forums/index.php?topic=15656.msg319816