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.

[Bonknuts]

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.

C

[Charlie]

Schematics updated, text edited 6/16.

Charlie

[Bonknuts]

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

[Bonknuts]

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