Fafalada said:
Vincenth said:
Besides, how big was the PSOne integrated in PS2?
Depends how you count ... and/or WHO is doing the counting.
1) Me for example would say it must have been a good deal smaller then EEGS IC since the "integrated PSOne" is in fact just the R3000 cpu aka the IOP.
There's no PSOne rasterizer present, nor the original MPEG decoder, etc. - certain parts of emulation are software based. (IOP can't control GS and IPU for one so those are partially ran by EE).
2) Now if you're nitpicking, the "integrated PSOne" includes the sound chip and respective sound and IOP memories
Of course this could immediately spring the debate - if SPU2 also counts as PSOne component (since it includes two SPU cores), is IPU also one since it can also decode MPEG1 streams?
3) Which brings me to the last point... if you're Deadmeat, the integreated PSOne measured about 18mm2 (GS area / 16) + IOP size.
If we include the (SPU/2) + 4mb DRam + IPU area from "
2)" we have just constructed a convincing piece of evidence that PS2 is in fact not a departure from PSOne architecture at all, it's clearly just extension in all major components (CPU, graphics, sound)
But I disgress, the point I was trying to make is that PSOne emulation is in part made easy because of all the resource sharing - IPU and SPU2 are both backwards compatible with respective units in PSOne, you have the CPU there etc.
Bolting EE&GS to PS3 is a bit more iffy to me. GS is completely redundant outside emulation (unless you can tell me what a rasterizer could do as an I/O processor
) and you don't get sound or PSOne with it either.
This is not what Katsura told everyone
IIRC doesn't the I/O CPU includes the DMAC ( IIRC it is in the PlayStation 2 docs ) and the GTE.
This is what Katsura wrote on this forum back in the days, he also added that it included the MDEC.
You make an excellent point about the SPU2 being basically backward compatible with SPU and about the IPU being able to decode MPEG1 streams, but is there difference between standard MPEG1 and Motion JPEG which is what the MDEC used ( AFAIK it was different from standard MPEG1 ) ?
I do not think PlayStation 3 would need the whole EE+GS and PSOne CPU: just cut the GS from the chip and use the EE@90 nm as PlayStation 3 I/O CPU ( it should be around 40 mm^2 now and using 4-8 Watts ).
The I/O ASIC, as seen in the patent, is connected to external RAM: well, we might assume the I/O ASIC also contains the Memory Controller for the XDR Memory Pool.
In the case I made about an over-all 102.4 GB/s XDR and no e-DRAM ( while I still agree that it would be better, considering future die shrinks for the system chips, using e-DRAM ) we would still be ok as we can connect the I/O ASIC to the CELL CPU through a fast Redwood link.
PSOne CPU can be emulated in software by the CELL CPU very accurately ( enough difference in power, plus JIT compilation can be used ) and the CELL GPU would be enhanced for GS backward-compatibility ( nothing major though ) and the GS would be sort of emulated using the system's GPU.
As Sound Processor I think they will be using the VME also present in the PSP and in the newest NetMD models: at 166 MHz, in the PSP, it reaches 5 GOPS and can do 7.1 channels Music and Sound.
The VME would have its own Sound RAM.
No need of Direct RDRAM in the system as we are using Yellowstone.
For PlayStation 2 backward-compatibility mode ( btw, most if not all PSOne's CPU software core should be able to reside in the LS on the APUs [total of 32x128 KB = 4 MB] ) we set the base clock of Yellowstone ( which is the external clock which runs off chip [as you know in the Mmemory Controller and in the DRAM chips we have ODR signalling data rates] ) to 100 MHz.
100 MHz * 4 ( PLL ) * 2 = 800 MHz signalling rate, same as Direct RDRAM.
The EE has a Memory Contoller embedded and thsi controller has onky support fro double channel Direct RDRAM: this means support for 2x16 bits data busses and the data is multiplexed with the addresses.
When we put the EE in the I/O ASIC we can as well add an intermediary stage ( a MUX basically ) that receives data and address from/to memory.
Simplier would be to take the EE and replace the Direct RDRAM Memory Controller and replace it with a 64-128 bits XDR ( I still call it Yellowstone ) Memory Controller: in PlayStation 2 backward-compatibility mode only 32 bits would be active and usable ).
Edit:
No need of replacing fully the Memory Controller of the EE.
We would have a XDR Memory Controller in the I/O ASIC ( which is connected by a fast Redwood interface to the CELL CPU ) that feeds appropriately the EE portion of the chip as it would expect, especially in PlayStation 2 backward-compatibility mode.
this would enlarge the I/O ASIC a bit, but it would me much easier on the re-engineering side of things than replacing the EE's Memory Controller and do some trickes to feed both EE and the CELL CPU from that Memory Controller.
We could set XDR's external clock to 100 MHz, get 800 MHz of data signalling rate and the same bandwidth to main memory that the EE had.
800 MHz * 32 bits/cycle = 3.2 GB/s
Now, I do not think changing the Memory Controller of the EE and stripping the GS from the combined chip ( EE+GS@90 nm ) would be something unfeasible or unpractical for SCE and Toshiba.
For PlayStation 3 normal mode the Memory Controller would operate at full speed and full "bit-ness" and the XDR base clock would be set to 400-800 MHz ( depending if we use a 3.2-6.4 GHz data signalling rate).
