What is the NEC D91317GD's purpose?

[thesteve]

It's a bit more than simple glue
It takes the CD info and delivers it to different systems
Has a memory mapper that drives CE on the non system ram chips
Calls IRQ to halt CPU,  so it can write to system ram

[Bonknuts]

It's a bit more than simple glue
It takes the CD info and delivers it to different systems
Has a memory mapper that drives CE on the non system ram chips
Calls IRQ to halt CPU,  so it can write to system ram

You mean so the main CPU can transfer data to ram? There are no DMA units in the PCE CD setup, that halt the cpu and over write memory directly on the cpu's address bus. All memory transfer to the PCE external mapped ram (8k system, 64k CD, 192k SCD) is done by the CPU.

 Unless you mean ADPCM ram, which isn't on the PCE side - which does have a DMA from the CD unit to ADPCM ram independent of the CPU (cpu keeps running, doesn't have to poll ports, and isn't halted). There's no halting of the cpu because it can only access it via a port, so no need to. The interrupt request, afaik and have seen/used, is for ADPCM DMA streaming from the CD. It's to tell the CPU than the buffer is full and to switch the address in the ADPCM chip to play the new buffer position (continuous streaming). You need this for the ADPCM CPLAY bios routine. So no halting the cpu for transfer. All other interfacing with the CD unit/mcu/logic requires polling status ports by the man CPU.
 

[thesteve]

Yes the DMA chip can write directly to CPU ram when the IRQ pin is held low

[Bonknuts]

You mean the /RDY pin? Holding down the IRQ pin does nothing but request a CPU interrupt (which doesn't halt the cpu or address/data bus in anyway). I'm pretty sure the cpu does not have tri-state or even buffered address/data bus lines (this has been talked about quite a few times over the years for making special hardware on the cart port, like a DMA chip to the VDC). So it won't be accessing anything in the base PCE unit (8k system ram, or ram on cart).

 *If* the base 64k CD work ram is behind some sort of bus arbitration logic chip, then the CPU could be halted with /RDY (which is only available on the back plane) and ram safely updated. But if the chip is capable of this, you can't access or use this feature. The system card bios routines have all been disassembled. All the routines manually read from the cd data interface port to transfer to CD work ram/etc. Not even the later updated/new BIOS routines via software (some late gen games did this) that directly access the CD ports/hardware - do anything like requesting some DMA mode.

 Like I said before, the only DMA request available is to ADPCM ram; again, it is not mapped to the cpu address bus so /RDY is not needed (you poll the ADPCM status port for an access slot for read/writes to the PORT. The cpu has no direct connection to ADPCM RAM). The ADPCM request does issue IRQ pin, if streaming mode is enabled, but doesn't halt the CPU. It interrupts main or sub code, and the CPU itself jumped to an interrupt vector to change the pointer of the ADPCM playback state. Again, the cpu isn't halted during ADPCM DMA.

 I think you're using some wrong terms/labels, or maybe thinking about the MCU on the cd base side? IRQ request and DMA are ADPCM functions only. ADPCM ram != CD ram. The only reason I'm making a clarification here, is that it would have been awesome if the CD unit could DMA directly to CD ram, like it can ADPCM ram. That would make realtime streaming data during game logic, soo much more flexible and powerful. As it is, huvideo wastes a lot of cpu resource polling and manually copying data from the CD port to CD ram. And that Warriors of Fate CD game wouldn't have been limited to 30 frame per second, interleaving game logic and reading from the CD unit every other frame.

[Sephirothkefka]

You mean the /RDY pin? Holding down the IRQ pin does nothing but request a CPU interrupt (which doesn't halt the cpu or address/data bus in anyway). I'm pretty sure the cpu does not have tri-state or even buffered address/data bus lines (this has been talked about quite a few times over the years for making special hardware on the cart port, like a DMA chip to the VDC). So it won't be accessing anything in the base PCE unit (8k system ram, or ram on cart).

 *If* the base 64k CD work ram is behind some sort of bus arbitration logic chip, then the CPU could be halted with /RDY (which is only available on the back plane) and ram safely updated. But if the chip is capable of this, you can't access or use this feature. The system card bios routines have all been disassembled. All the routines manually read from the cd data interface port to transfer to CD work ram/etc. Not even the later updated/new BIOS routines via software (some late gen games did this) that directly access the CD ports/hardware - do anything like requesting some DMA mode.

 Like I said before, the only DMA request available is to ADPCM ram; again, it is not mapped to the cpu address bus so /RDY is not needed (you poll the ADPCM status port for an access slot for read/writes to the PORT. The cpu has no direct connection to ADPCM RAM). The ADPCM request does issue IRQ pin, if streaming mode is enabled, but doesn't halt the CPU. It interrupts main or sub code, and the CPU itself jumped to an interrupt vector to change the pointer of the ADPCM playback state. Again, the cpu isn't halted during ADPCM DMA.

 I think you're using some wrong terms/labels, or maybe thinking about the MCU on the cd base side? IRQ request and DMA are ADPCM functions only. ADPCM ram != CD ram. The only reason I'm making a clarification here, is that it would have been awesome if the CD unit could DMA directly to CD ram, like it can ADPCM ram. That would make realtime streaming data during game logic, soo much more flexible and powerful. As it is, huvideo wastes a lot of cpu resource polling and manually copying data from the CD port to CD ram. And that Warriors of Fate CD game wouldn't have been limited to 30 frame per second, interleaving game logic and reading from the CD unit every other frame.

Well you learn something new everyday.

[thesteve]

i do know the IRQ is sourced directly from the D91317 not either of the cd side processors
the cd system has 2 processors dedicated to command and data translation between the CD bus and the sony chipset
the D91317 appears to be the interface processor seperating the different systems (CD/ADPCM/syscard)
it also controls a set of tristate bus chips between CPU and interface bus