• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
  • The Politics forum has been nuked. Please do not bring political discussion to the rest of the site, or you will be removed. Thanks.

What's in a name? Reduced PS1, 2, 3 game load times. By any other name would be just as sweet.

GAFfe machine

Member
Dec 18, 2019
78
463
400
This post is the third of three (the first can be read here, the second can be read here) that started off as a reply I couldn't post before the PS5/XSX tech speculation thread closed. I decided to thread the reply to catch as many eyeballs as possible and maybe spark some discussion.

Back when the tech thread was still open LiquidRex posted a pic of PS5's SSD controller and asked why it bears the name 'YAMAZAKI', after a brand of Japanese whisky. The question prompted Hashi to guess that maybe the SSD controller was named after Takeshi Yamazaki. An SIE engineer who was at the forefront of R&D'ing the Emotion Engine and CELL Broadband Engine architectures.

I'm inclined to think that Hashi guessed right because one of the original I/O complex + SSD patents filed by Hideyuki Saito (an SIE engineer who helped IBM test CELL's functional correctness (under 7. ACKNOWLEDGEMENTS) and devised the I/O complex + SSD's data access request and address translation schemes) cites another patent (US8504736B2) for a file input/output scheduler (FIOS) that runs on CELL (specifically its SPUs).

Interestingly, that FIOS patent cites another patent for a CELL-accelerated NIC server board of which Yamazaki is listed as a co-inventor (for those who care, these server boards were used by Sony/SIE for their streaming services; the link to the intro of the server board whitepaper can be found in this OP embedded in the words 'network processing'). Although the patent details the specific invention of data transfer from a CELL to a NIC, language in one of the patent entries encapsulates two defining characteristics of Yamazaki's SSD controller which are in the bolded text below:

[0004]
The present invention has been conceived in view of the above-described situation, and an object of the invention is to provide an information processing device, data transfer method and information storage medium that can commence data transfer to an I/O device immediately, and can stably exhibit data transfer performance.

To piggy-back off Hashi's guess, my guess is that Yamazaki's expertise in developing devices and methods for high-speed data management led Masayasu Ito (SVP of hardware engineering/operations) to entrust him with the responsibility of customizing PS5's SSD controller, hence the name 'YAMAZAKI' is tattooed on its silicon.

But I think Yamazaki did more than just design/customize PS5's SSD controller. Given the configuration and overall operation of the Zen 2 + I/O complex + SSD controller system I'd hazard a guess that he was responsible for designing PS5's I/O complex too, which may work to speed up PS1, 2, 3 game loading. Before I get to how, there are four patent entries from his CELL + NIC patent (entries [0013], [0014], [0015], [0019]) that jibe with eight patent entries from Saito's I/O complex + SSD patent (entries [0019], [0030], [0050], [0051], [0052], [0062], [0068], [0074]). When compared, these twelve entries show that CELL had an outsized influence on the configuration and overall operation of the Zen 2 + I/O complex + SSD controller system to the point where the line between the two inventions is blurred. Below is a like-for-like comparison of the aforementioned patent entries highlighting similarities between the two inventions. The comparison gets into the weeds so those still reading please bear with me:

The CELL Broadband Engine is an "information processing device" consisting of (focusing on CPUs only) a main processor and sub-processors connected to a bus:

[0013]
As shown in FIG. 1, this information processing device 10 includes a main processor 12 and a plurality of sub-processors 24-1 to 24-n, and is constructed as an asymmetric multi-core processor... The main processor 12 and the plurality of sub-processors 24-1 to 24-n are all connected to a bus 22,...

The Zen 2 + I/O complex (also referred to as the "host unit") are parts of an "information processing device" consisting of (focusing on CPUs only) a main CPU and sub-CPUs connected by a bus:

[0019]
An information processing device 10 includes a host unit 12,

[0050]
The host unit 12 includes a main CPU 30, a sub-CPU 32, and a memory controller 34 connected together by a coherent bus 36.
The DMAC inside a CELL's SPE (sub-processor) is used to bypass the main processor (PPE) when accessing data stored in main memory (i.e. system memory):

[0015]
The sub-processors 24 (24-1 to 24-n) are ancillary program execution means containing local memory 24 a, a memory management section 24 b and a DMAC (Direct Memory Access Controller)... The DMAC 24 c is also a control unit for direct access to the main memory 14, without going via the main processor 12.

The DMAC inside the I/O complex in conjunction with an adjacent I/O co-processor (specifically the one "dedicated to SSD I/O" -- timestamped) is used to bypass the main CPU (Zen 2) when accessing the requested data stored in system memory:

[0068]
When the data passes the ECC check, the data in question is stored in a kernel area 70 of the system memory 14 reserved in advance by the sub-CPU 32, for example, by a DMAC not illustrated, and the sub-CPU 32 is notified to that effect (S44).
With CELL, the PPE (main-processor) and SPE (sub-processor) page sizes are the same. These pages (data) are strictly 4KB, 64KB, 1MB or 16MB in size (i.e. page granularity levels), and are grouped into an address translation table to be referred to by an SPE:

[0015]
The sub-processors 24 (24-1 to 24-n) are ancillary program execution means containing local memory 24 a, a memory management section

[0014]
The address translation table is a table which associates logical addresses with physical addresses, and is made up of page groups of a specified size such as 4 KB. Therefore, the memory management section 12 a is provided with a memory for storing the necessary pages, of these pages,


With the Zen 2 + I/O complex + SSD controller system, the Zen 2 (main-CPU), I/O co-processors (sub-CPUs) and SSD controller (a sub-CPU outside the I/O complex) page sizes are the same. These pages (data) are strictly 4KB, 64KB, 1MB or 16MB in size (i.e. page granularity levels), and are grouped into an address translation table to be referred to by the SSD controller:

[0051]
Although it is not necessary for the main and sub-CPUs 30 and 32 to have the same instruction set architecture and operating system, the main and sub-CPUs 30 and 32 are connected by the coherent bus 36 and their page sizes are the same so that data stored in the system memory 14 can be shared between them.

[0062]
The flash controller 18 not only handles the data storage in question but also generates an address conversion table for associating a logical address of compressed data and a physical address of an area where the actual data is stored.

[0030]
A plurality of address spaces different in granularity level are defined in the address conversion table... It should be noted that there may be three or more granularity levels.

[0074]

The benefit of using CELL's SPE (sub-processor) to handle data transfers from system memory rather than its PPE (main-processor) is high-speed data transfer:

[0019]
According to the above described information processing device 10, since a single sub-processor 24-1 constituting a multi-core processor is allocated solely to data transfer, it is possible to implement data transfer at high speed and with low latency regardless of the operating state of the main processor 12.

The benefit of using the I/O complex's SSD I/O co-processor (sub-CPU) to access system memory and a flash controller (sub-CPU) to access data in flash memory rather than Zen 2 (main-CPU), is high speed data transfer:

[0052]
The sub-CPU 32 divides a file read request issued by the main CPU 30 into read requests for data of a given size, storing the requests in the system memory 14. Thus, in the present embodiment, hardware other than the main CPU 30 handles the major part of data access to the flash memory 20, and the read unit is reduced to a finer one immediately after issuance of a file access request. This allows for parallel access to a plurality of NAND devices, thus providing a high transfer rate.

To summarize the similarities between the two patents...

  • the respective patents refer to both CELL and the Zen + I/O complex as an "information processing device". CELL's PPE is its main processor (or main-CPU) and its SPEs are its sub-processors (or sub-CPUs). Zen 2 is the I/O complex's main CPU (or main processor) and the two I/O co-processors inside the I/O complex along with the SSD controller outside the I/O complex are sub-CPUs (or sub-processors).

  • the SPE (equipped with an internal DMAC) facilitates high-speed data transfers so that the main processor (PPE) doesn't have to. The I/O-coprocessor inside the I/O complex dedicated to SSD I/O along with an adjacent DMAC facilitate high speed data transfers so that the main CPU (Zen 2) doesn't have to.

  • CELL's SPE (sub-CPU) and PPE (main CPU) have the same page (data) sizes which are 4KB, 64KB, 1MB or 16MB (i.e. page granularity levels). The SPE refers to an address translation table to locate data. Zen 2 (main-CPU), the I/O-coprocessor (sub-CPU inside the I/O complex) dedicated to SSD I/O and the SSD controller (sub-CPU outside the I/O complex) have the same page sizes which are 4KB, 64KB, 1MB or 16MB. The SSD controller refers to an address translation table to locate data.

Other similarities not part of the two patents, but which I thought were worth mentioning as they show CELL's heavy influence on the I/O complex's design are:


[0111]
By way of example, in the certain cell processor architectures, the SPE 206 have a local store capacity of 256 Kbytes. This is often sufficient memory space for the compressed input, the decompressed output and the code for the decompression algorithm




Extremely long story short, it seems someone had CELL on the brain when designing PS5's I/O complex (something I expressed to PaintTinJr in the past) and how it works with Zen 2 and the SSD controller. To my mind that someone was Yamazaki given how CELL-like the entire I/O system is and I have a feeling he designed/customized the I/O system to do more than just transfer data around inside PS5, which brings me to the title of this OP.

In another post of mine, I raised the prospect of a CELL/RSX-based compatibility adaptor. A secondary function of PS5's I/O system might be to fast-feed PS1, 2 or 3 game file data from PS5's SSD to the internal storage of that presumed CELL/RSX-based compatibility adaptor. Basically, a CELL-inspired system (i.e. the Zen 2 + I/O complex + SSD controller system) that rapidly feeds a CELL-based device (i.e the CELL/RSX-based compatibility adaptor) in the service of backwards compatibility.

By this I mean once a user has selected a previously downloaded PS1, 2 or 3 game (purchased from the PS Store in the past or rented from PS Now) to play from an SSD, Zen 2 tells the adaptor to ready itself for the selected game. Once ready, the adaptor tells Zen 2 which then tells the SSD I/O co-processor inside the I/O complex to have the SSD controller read the selected legacy game's file data from an SSD and forward it in 4KB, 64KB, 1MB or 16MB chunks to the adaptor's internal flash storage via ethernet cable.

As the game file data arrives and is stored in the adaptor's flash storage, CELL quickly accesses it under a scheme similar to PS5's (i.e. using two or more priority levels) and processes it according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads sent from PS5's SSD to the adaptor are already chunked in 4KB, 64KB, 1MB or 16MB sizes the way CELL likes it. After the CELL/RSX-based adaptor renders a frame of the legacy game, the frame is then sent via ethernet cable to PS5's system memory, pulled out by Oberon and is either displayed as is or spruced up/upscaled before being displayed.

Likewise, a similar process would exist for disc-based PS1, 2, 3 titles in which PS5's disc drive reads the disc and sends signals containing game data to the adaptor. Once received, the adaptor extracts the game data from the signal and forwards the data to its internal flash storage to be accessed from there and processed according to the legacy console it belongs to.

How sweet would that be?
 
Last edited:

Quazar77

Member
Jan 7, 2018
1,384
2,210
445
Montreal
www.supermassivequazar.ca
This post is the third of three that started off as a reply to a member in the now shuttered PS5/XSX tech thread. Since I couldn't post my reply before the closure, I decided to "thread" the reply and post it at a time of my choosing as my final bit of PS5-related tech speculation. With that out the way...

Back when the tech thread was still open LiquidRex posted a pic of PS5's SSD controller and asked why it carried the name 'YAMAZAKI', after a brand of Japanese whisky. The question prompted Hashi to guess that maybe the SSD controller was named after Takeshi Yamazaki. An SIE engineer who was at the forefront of R&D'ing the Emotion Engine and CELL Broadband Engine architectures.

I'm inclined to think that Hashi guessed right because one of the original I/O complex + SSD patents filed by Hideyuki Saito (an SIE engineer who helped IBM test CELL's functional correctness (under 7. ACKNOWLEDGEMENTS)) and devised the I/O complex + SSD's data access request and address translation schemes) cites another patent (US8504736B2) for a file input/output scheduler (FIOS) that runs on CELL (specifically its SPUs).

Interestingly, that FIOS patent cites another patent for a CELL-accelerated NIC server board of which Yamazaki is listed as a co-inventor (for those who care, these server boards were used by Sony/SIE for their streaming services; the link to the intro of the server board whitepaper can be found in this OP embedded in the words 'network processing'). Although the patent details the specific invention of data transfer from a CELL to a NIC, language in one of the patent entries encapsulates two defining characteristics of Yamazaki's SSD controller which are in the bolded text below:



To piggy-back off Hashi's guess, my guess is that Yamazaki's expertise in developing devices and methods for high-speed data management led Masayasu Ito (SVP of hardware engineering/operations) to entrust him with the responsibility of customizing PS5's SSD controller, hence 'YAMAZAKI' tattooed on its silicon.

And given the configuration and overall operation of the Zen 2 + I/O complex + SSD controller system, I'd also hazard a guess that he was responsible for the I/O complex too. Yamazaki knows CELL inside-out and there are two patent entries (i.e. [0004], [0015]) in his CELL + NIC patent that jibe with five patent entries (i.e. [0051], [0052], [0053], [0064], [0074]) in Saito's I/O complex + SSD patent. These seven entries blur the line between CELL and the Zen 2 + I/O complex + SSD controller system. Below is a like-for-like comparison of the aforementioned patent entries highlighting similarities between the two inventions. The comparison gets into the weeds so those still reading please bear with me:






To summarize the comparisons...

  • the respective patents refer to both CELL and the Zen + I/O complex as an "information processing device". CELL's PPE is its main processor (or main-CPU) and its SPEs are its sub-processors (or sub-CPUs). Zen 2 is the I/O complex's main CPU (or main processor) and the two I/O co-processors inside the I/O complex along with the SSD controller outside the I/O complex are sub-CPUs (or sub-processors).

  • the SPE (equipped with an internal DMAC) facilitates high-speed data transfers so that the main processor (PPE) doesn't have to. The I/O-coprocessor inside the I/O complex dedicated to SSD I/O along with an adjacent DMAC facilitate high speed data transfers so that the main CPU (Zen 2) doesn't have to.

  • CELL's SPE (sub-CPU) and PPE (main CPU) have the same page (data) sizes which are 4KB, 64KB, 1MB or 16MB (i.e. page granularity levels). The SPE refers to an address translation table to locate data. Zen 2 (main-CPU), the I/O-coprocessor (sub-CPU inside the I/O complex) dedicated to SSD I/O and the SSD controller (sub-CPU outside the I/O complex) have the same page sizes which are 4KB, 64KB, 1MB or 16MB. The SSD controller refers to an address translation table to locate data.

Other comparisons not part of the larger patent comparison are:





Extremely long story short, it seems someone had CELL on the brain when designing PS5's I/O complex (something I've thought in the past) and how it works with Zen 2 and the SSD controller. As I said earlier in the post, Yamazaki is the someone who comes to my mind given how CELL-like the unit is. And I have a feeling his SSD controller and likely I/O complex were probably designed/customized to do more than just access and transfer data off PS5's SSDs.

In another post of mine, I raised the prospect of a CELL/RSX-based compatibility adaptor. Fast-feeding PS1, 2 or 3 game file data from PS5's SSDs to the internal storage of that presumed compatibility adaptor might also be a secondary function of the I/O complex. Basically, a CELL-inspired system that rapidly feeds a CELL-based device in the service of backwards compatibility.

By this I mean once a user has selected a previously downloaded PS1, 2 or 3 game (purchased from the PS Store in the past or rented from PS Now) to play from an SSD, Zen 2 tells the adaptor to ready itself for the selected game. Once ready, the adaptor tells Zen 2 which then tells the SSD I/O co-processor inside the I/O complex to have the SSD controller read the selected legacy game's file data from an SSD and forward it in 4KB, 64KB, 1MB or 16MB chunks to the adaptor's internal flash storage via ethernet cable.

From there the data is quickly accessed under a scheme similar to PS5's (using two or more priority levels) and processed according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads coming from PS5's SSD are already chunked how CELL likes it. After frames of the legacy game have been rendered, they are then sent via ethernet cable to PS5's system memory, pulled out by Oberon and are either displayed as is or spruced up/upscaled before being displayed.

Likewise, a similar process would exist for disc-based PS1, 2, 3 titles in which PS5's disc drive reads the disc and sends signals containing game data to the adaptor. Once received, the adaptor extracts the game data from the signal and forwards the data to its internal flash storage to be accessed from there and processed according to the legacy console it belongs to.

How sweet would that be?
Nah he tweaking
 

JimboJones

Member
Apr 16, 2009
4,288
2,814
1,320
N.Ireland
You can decrease load times on emulators just by holding down a button, think it's tab on dolphin which makes the game run 2 x speed or I think as fast as your computer can allow if you select unlimited. I'm sure lots of emulators have similar options.
 
Last edited:

GAFfe machine

Member
Dec 18, 2019
78
463
400
Are you that guy who was always going on about the PS3 (or was it PS4) web browser and stuff? I don't remember his name or what his actual theory was, but this sure reminds me of that.

I think you're talking about Shifty Geezer. I'm not him but I can understand why you drew that parallel. :messenger_tears_of_joy:
 

cormack12

Gold Member
Mar 21, 2013
10,708
28,252
1,550
This post is the third of three that started off as a reply to a member in the now shuttered PS5/XSX tech thread. Since I couldn't post my reply before the closure, I decided to "thread" the reply and post it at a time of my choosing as my final bit of PS5-related tech speculation. With that out the way...

Back when the tech thread was still open LiquidRex posted a pic of PS5's SSD controller and asked why it carried the name 'YAMAZAKI', after a brand of Japanese whisky. The question prompted Hashi to guess that maybe the SSD controller was named after Takeshi Yamazaki. An SIE engineer who was at the forefront of R&D'ing the Emotion Engine and CELL Broadband Engine architectures.

I'm inclined to think that Hashi guessed right because one of the original I/O complex + SSD patents filed by Hideyuki Saito (an SIE engineer who helped IBM test CELL's functional correctness (under 7. ACKNOWLEDGEMENTS) and devised the I/O complex + SSD's data access request and address translation schemes) cites another patent (US8504736B2) for a file input/output scheduler (FIOS) that runs on CELL (specifically its SPUs).

Interestingly, that FIOS patent cites another patent for a CELL-accelerated NIC server board of which Yamazaki is listed as a co-inventor (for those who care, these server boards were used by Sony/SIE for their streaming services; the link to the intro of the server board whitepaper can be found in this OP embedded in the words 'network processing'). Although the patent details the specific invention of data transfer from a CELL to a NIC, language in one of the patent entries encapsulates two defining characteristics of Yamazaki's SSD controller which are in the bolded text below:



To piggy-back off Hashi's guess, my guess is that Yamazaki's expertise in developing devices and methods for high-speed data management led Masayasu Ito (SVP of hardware engineering/operations) to entrust him with the responsibility of customizing PS5's SSD controller, hence 'YAMAZAKI' tattooed on its silicon.

And given the configuration and overall operation of the Zen 2 + I/O complex + SSD controller system, I'd also hazard a guess that he was responsible for the I/O complex too. Yamazaki knows CELL inside-out and there are two patent entries (i.e. [0004], [0015]) in his CELL + NIC patent that jibe with five patent entries (i.e. [0051], [0052], [0053], [0064], [0074]) in Saito's I/O complex + SSD patent. These seven entries blur the line between CELL and the Zen 2 + I/O complex + SSD controller system. Below is a like-for-like comparison of the aforementioned patent entries highlighting similarities between the two inventions. The comparison gets into the weeds so those still reading please bear with me:






To summarize the comparisons...

  • the respective patents refer to both CELL and the Zen + I/O complex as an "information processing device". CELL's PPE is its main processor (or main-CPU) and its SPEs are its sub-processors (or sub-CPUs). Zen 2 is the I/O complex's main CPU (or main processor) and the two I/O co-processors inside the I/O complex along with the SSD controller outside the I/O complex are sub-CPUs (or sub-processors).

  • the SPE (equipped with an internal DMAC) facilitates high-speed data transfers so that the main processor (PPE) doesn't have to. The I/O-coprocessor inside the I/O complex dedicated to SSD I/O along with an adjacent DMAC facilitate high speed data transfers so that the main CPU (Zen 2) doesn't have to.

  • CELL's SPE (sub-CPU) and PPE (main CPU) have the same page (data) sizes which are 4KB, 64KB, 1MB or 16MB (i.e. page granularity levels). The SPE refers to an address translation table to locate data. Zen 2 (main-CPU), the I/O-coprocessor (sub-CPU inside the I/O complex) dedicated to SSD I/O and the SSD controller (sub-CPU outside the I/O complex) have the same page sizes which are 4KB, 64KB, 1MB or 16MB. The SSD controller refers to an address translation table to locate data.

Other comparisons not part of the larger patent comparison are:





Extremely long story short, it seems someone had CELL on the brain when designing PS5's I/O complex (something I expressed in the past) and how it works with Zen 2 and the SSD controller. As I said earlier in the post, Yamazaki is the someone who comes to my mind given how CELL-like the unit is. And I have a feeling his SSD controller and likely I/O complex were probably designed/customized to do more than just access and transfer data off PS5's SSDs.

In another post of mine, I raised the prospect of a CELL/RSX-based compatibility adaptor. Fast-feeding PS1, 2 or 3 game file data from PS5's SSDs to the internal storage of that presumed compatibility adaptor might also be a secondary function of the I/O complex. Basically, a CELL-inspired system that rapidly feeds a CELL-based device in the service of backwards compatibility.

By this I mean once a user has selected a previously downloaded PS1, 2 or 3 game (purchased from the PS Store in the past or rented from PS Now) to play from an SSD, Zen 2 tells the adaptor to ready itself for the selected game. Once ready, the adaptor tells Zen 2 which then tells the SSD I/O co-processor inside the I/O complex to have the SSD controller read the selected legacy game's file data from an SSD and forward it in 4KB, 64KB, 1MB or 16MB chunks to the adaptor's internal flash storage via ethernet cable.

From there the data is quickly accessed under a scheme similar to PS5's (using two or more priority levels) and processed according to the legacy console it belongs to. Possibly resulting in quicker load times because the data reads coming from PS5's SSD are already chunked how CELL likes it. After frames of the legacy game have been rendered, they are then sent via ethernet cable to PS5's system memory, pulled out by Oberon and are either displayed as is or spruced up/upscaled before being displayed.

Likewise, a similar process would exist for disc-based PS1, 2, 3 titles in which PS5's disc drive reads the disc and sends signals containing game data to the adaptor. Once received, the adaptor extracts the game data from the signal and forwards the data to its internal flash storage to be accessed from there and processed according to the legacy console it belongs to.

How sweet would that be?
Yes.
 

Aldynes

Member
Jun 24, 2016
283
531
430
France
OP I got a question, if I've understood the PS5 got something very useful in regard of running PS1/2/3 titles in emulation with the benefits that comes with the use of an SDD for loading times and could possibly run theses old titles at twice the speed / framerate ?

So in short something similar to Xbox FPS boost program but with the PS catalog of stuff you already bought on the PS store for exemple?

Maybe this was the plan when they talked about retro-compatibility, I was so let down when this got scrapped for the PS5, that's the main reason I choose a Series X first.
 
  • Thoughtful
Reactions: GAFfe machine

GAFfe machine

Member
Dec 18, 2019
78
463
400
No, I found him, it was Jeff Rigby.

Ahh, you beat me to it! Jeff Rigby, that's the guy. No, I'm not him and how I got him confused with Shifty Geezer is crazy to me. I knew exactly the character you described, knew his name and was familiar with his posts; yet somehow his name escaped me and I got him twisted with Shifty Geezer... 🤦‍♂️

Good stuff RoadHazard.(y)
 
Last edited:

RoadHazard

Member
Dec 9, 2008
20,922
3,970
1,255
Gothenburg, Sweden
Ahh, you beat me to it! Jeff Rigby, that's the guy. No, I'm not him and how I got him confused with Shifty Geezer is crazy to me. I knew exactly the character you described, knew his name and was familiar with his posts; yet somehow his name escaped me and I got him twisted with Shifty Geezer... 🤦‍♂️

Good stuff RoadHazard.(y)

Good job filling his shoes! Haha.
 
  • Fire
Reactions: GAFfe machine

GAFfe machine

Member
Dec 18, 2019
78
463
400
OP I got a question, if I've understood the PS5 got something very useful in regard of running PS1/2/3 titles in emulation with the benefits that comes with the use of an SDD for loading times and could possibly run theses old titles at twice the speed / framerate ?

So in short something similar to Xbox FPS boost program
but with the PS catalog of stuff you already bought on the PS store for exemple?

Maybe this was the plan when they talked about retro-compatibility, I was so let down when this got scrapped for the PS5, that's the main reason I choose a Series X first.

Not for running emulation by itself. For quickly retrieving PS1, 2 or 3 game file data in 4KB, 64KB, 1MB or 16MB chunks from the SSD, and sending that game file data over to a separate CELL/RSX-based compatibility adapter connected to PS5 with an ethernet cable.

After sending the game file data over to the adapter's internal storage, the PS5 would wait for the adapter to process it and send fully rendered frames of the legacy title (e.g.Jak 2) back over to it through the ethernet cable. At that point the PS5 would do one of two things with the rendered frame: Either display the frame as is or enhance/upscale the frame before displaying it.

If a FPS boost is to be achieved, it would most likely have to be done by the adapter. The 4 PPE/32 SPE Quad CELL + butterflied RSX I mentioned in this OP would have enough giddyap to do it. SIE could probably implement a system level FPS boost feature, but with the adapter I described the resolution would likely be capped at 2K because of all the other processing it would have to do. An adapter with 64 SPEs could overcome this though.
 
Last edited:
  • Thoughtful
Reactions: Aldynes

Aldynes

Member
Jun 24, 2016
283
531
430
France
Not for running emulation by itself. For quickly retrieving PS1, 2 or 3 game file data in 4KB, 64KB, 1MB or 16MB chunks from the SSD, and sending that game file data over to a separate CELL/RSX-based compatibility adapter connected to PS5 via an ethernet cable.

After sending the game file data over to the adapter's internal storage, the PS5 would wait for the adapter to process it and send fully rendered frames of the legacy title (e.g.Jak 2) back over to it through the ethernet cable. At that point the PS5 would do one of two things with the rendered frame: Either display the frame as is or enhance/upscale the frame and display it.

If a FPS boost is to be achieved, it would most likely have to be done by the adapter. The 4 PPE/32 SPE Quad CELL + butterflied RSX I mentioned in this OP would have enough giddyap to do it. SIE could probably implement a system level FPS boost feature, but with the adapter I described the resolution would likely be capped at 2K because of all the other processing it would have to do. An adapter with 64 SPEs could overcome this though.
This is interesting stuff good job! There's several options for SONY to have backward compatibility via either a adapter/add-on to buy separately or a new PS5 model/revision with this stuff integrated based on that PS3 patent you've mentioned?

So it could happen on a technical level and it's doable, but will SONY do it? Based on their backward mentality (no pun intended) on game preservation and Jim Ryan views on old games...
 

RoadHazard

Member
Dec 9, 2008
20,922
3,970
1,255
Gothenburg, Sweden
Not for running emulation by itself. For quickly retrieving PS1, 2 or 3 game file data in 4KB, 64KB, 1MB or 16MB chunks from the SSD, and sending that game file data over to a separate CELL/RSX-based compatibility adapter connected to PS5 via an ethernet cable.

After sending the game file data over to the adapter's internal storage, the PS5 would wait for the adapter to process it and send fully rendered frames of the legacy title (e.g.Jak 2) back over to it through the ethernet cable. At that point the PS5 would do one of two things with the rendered frame: Either display the frame as is or enhance/upscale the frame and display it.

If a FPS boost is to be achieved, it would most likely have to be done by the adapter. The 4 PPE/32 SPE Quad CELL + butterflied RSX I mentioned in this OP would have enough giddyap to do it. SIE could probably implement a system level FPS boost feature, but with the adapter I described the resolution would likely be capped at 2K because of all the other processing it would have to do. An adapter with 64 SPEs could overcome this though.

So basically you want 4 (or 8) PS3s in a tiny box? I don't really see the need for this given that the PS5 could easily emulate all of these consoles at 4K if Sony just gave a damn. Maybe you covered this in your original post though, it was too long to read...
 
  • Empathy
Reactions: GAFfe machine

GAFfe machine

Member
Dec 18, 2019
78
463
400
So basically you want 4 (or 8) PS3s in a tiny box? I don't really see the need for this given that the PS5 could easily emulate all of these consoles at 4K if Sony just gave a damn. Maybe you covered this in your original post though, it was too long to read...

I covered it in "1)" of this OP. Comments by the RPCS3 team members I referenced leave me with the impression that PS5's CPU won't be able to emulate CELL one-to-one. Even CPUs clocked higher than 3.5 GHz can't do it, so how on earth can PS5's CPU do it.

It seems to me that the only real solution is a hardware one. Whether that be the equivalent of 4 (or 8) PS3s in a tiny box or customizations to PS5's CPU that allow it to perfectly emulate the "quirks" of the SPE's Memory Flow Controller (MFC), which I doubt PS5's CPU has.

In the case of CELL perfect emulation isn't just about brute-force, it's about finesse too.
 
Last edited:
  • Thoughtful
Reactions: sn0man and Aldynes

Drew1440

Member
Nov 12, 2020
169
130
205
There was speculation that the Tempest engine was basically the PS3 cell CPU, not sure it that's true. The last Cell that IBM released was the PowerXCell 8i
 
Last edited:
  • Like
Reactions: GAFfe machine

GAFfe machine

Member
Dec 18, 2019
78
463
400
There was speculation that the Tempest engine was basically the PS3 cell CPU, not sure it that's true. The last Cell that IBM released was the PowerXCell 8i

It isn't true. Forum-goers erroneously claim that the Tempest Engine is basically a CELL, but Cerny said it's basically an SPU...


If the Tempest Engine was basically a CELL, it would've had an integrated main CPU of its own to run an OS and control the cache-less "SPU-like Architecture".

I've seen my share of speculation on the Tempest Engine emulating CELL, and none of it is convincing. For one thing, I just can't wrap my noodle around the notion of a slower GPU compute unit clocked at 2.23 GHz accurately emulating a faster CPU clocked at 3.2 GHz.
 
Last edited:
  • Thoughtful
Reactions: sn0man

GAFfe machine

Member
Dec 18, 2019
78
463
400
That is the worst thread title I may have ever seen on this forum.

Really? I didn't think it would be that bad. Given the nods to Shakespeare that Cerny (or whoever) made by naming PS5's APU 'Oberon' and its audio chip 'Tempest', I figured I'd keep with the Shakespearean theme for my OP. The title is my spin on an often recited line from one of Shakespeare's plays:

"What's in a name? That which we call a rose
By any other name would smell as sweet." -- Juliet

Maybe you caught that, or maybe you didn't. If you didn't, then the following may give you a different perspective on the title:

The OP is about the name of an engineer who designed PS5's SSD controller and was most likely responsible for designing PS5's I/O complex, which I suspect works with a yet to be announced backwards compatibility adapter to reduce PS1, 2, 3 game load times. If this turns out to be the case, then I think that would be "sweet" (as in fantastic) and I'll credit Takeshi Yamazaki for that. And even if I'm wrong about the name of who should be credited, jumping into a PS1, 2 or 3 game (be it on disc or download) in half the time or less would be "sweet" regardless of the engineer's name who made it possible.
 
Last edited:

thatJohann

Member
Jun 26, 2007
2,219
619
1,420
Brooklyn, NY
Really? I didn't think it would be that bad. Given the nods to Shakespeare that Cerny (or whoever) made by naming PS5's APU 'Oberon' and its audio chip 'Tempest', I figured I'd keep with the Shakespearean theme for my OP. The title is my spin on an often recited line from one of Shakespeare's plays:



Maybe you caught that, or maybe you didn't. If you didn't, then the following may give you a different perspective on the title:

The OP is about the name of a engineer who designed PS5's SSD controller and was most likely responsible for designing PS5's I/O complex, which I suspect works with a yet to be announced backwards compatibility adapter to reduce PS1, 2, 3 game load times. If this turns out to be the case, then I think that would be "sweet" (as in fantastic) and I'll credit Takeshi Yamazaki for that. And even if I'm wrong about the name of who should be credited, jumping into a PS1, 2 or 3 game (be it on disc or download) in half the time or less would be "sweet" regardless of the engineer's name who made it possible.
 

sn0man

Member
Nov 23, 2013
1,447
964
620
OP, would this only make sense if there was a plan for a PS5 PRO or whatever. If your talking about some cheap add-on to make backwards compatible PS1–3 games on PS5 then wouldn’t Sony rather prefer to have it all built into the same system?

my thinking is that on a pro you could overcome the MHz gulf by just having a mods the cpu goes into to run with less stuff turned on but at a higher rate.
 
  • Thoughtful
Reactions: GAFfe machine

GAFfe machine

Member
Dec 18, 2019
78
463
400
OP, would this only make sense if there was a plan for a PS5 PRO or whatever. If your talking about some cheap add-on to make backwards compatible PS1–3 games on PS5 then wouldn’t Sony rather prefer to have it all built into the same system?

my thinking is that on a pro you could overcome the MHz gulf by just having a mods the cpu goes into to run with less stuff turned on but at a higher rate.

Love the idea of a PS5 pro or "plus" having the hardware built in. It makes good sense to me and would be much preferred over having to deal with more wires and an adapter taking up more space alongside PS5.

PS5's Zen 2 CPU already overcame the GHz gulf between PS4's Jaguar and CELL (i.e. Jaguar at 1.6 GHz vs. CELL at 3.2 GHz vs. Zen 2 at up to 3.5 GHz), so I don't think the issue is clock speed. More than anything else, the issue seems to be a problem of emulating the way the SPE's Memory Flow Controller handles accesses to system memory. If SIE were to build a PS5 pro or "plus" that's backwards compatible with PS1– 3, it would likely have to add hardware to each CPU core that precisely mimics each SPE's MFC. But I have no clue how that can be done without breaking the CPU SIE would plan to use for a PS5 pro or "plus".
 
Last edited:
  • Like
Reactions: sn0man