DCEmu Homebrew Emulation & Theme Park NewsQuick post: I'm almost 100% sure that LCD type autodetection is not and will never be possible. The /RD signal of the LCD is just not connected, so despite the fact that the LCD has a specific register to identify the model, it cannot be read.
Makes sense: maintaining two or more firmwares is definitely something to avoid, so if the makers of the A320 are doing it, it's because that's the only way.
Please, note that they use a trick to somewhat alleviate the problem: the LCD initialization code is stored in a special place in the NAND flash which is never touched when performing normal firmware updates. However, those of you that have used the unbricking tool have noticed that when restoring from scratch, one has to specify the LCD model by selecting the appropriate .DL file.
So, for the time being, there will be two releases, one for each LCD type. We cannot use the trick that the original firmware does because we cannot use the NAND flash to store settings. However, if (when) linux becomes a firmware replacement, we'll go that way.
Makes sense: maintaining two or more firmwares is definitely something to avoid, so if the makers of the A320 are doing it, it's because that's the only way.
Please, note that they use a trick to somewhat alleviate the problem: the LCD initialization code is stored in a special place in the NAND flash which is never touched when performing normal firmware updates. However, those of you that have used the unbricking tool have noticed that when restoring from scratch, one has to specify the LCD model by selecting the appropriate .DL file.
So, for the time being, there will be two releases, one for each LCD type. We cannot use the trick that the original firmware does because we cannot use the NAND flash to store settings. However, if (when) linux becomes a firmware replacement, we'll go that way.
News Categories
Sony Consoles News
DCEmu News Archive
Menu
Forum Stats