個人の感想：ミクさんカバー使えない…..T_T これは予想外だった。
CPU：アーキテクチャ据え置きだが1.6GHzから2.1GHz メモリー GDDR5 8GB同じですがクロック高くなり176GB/sから218GB/s GPU：規模が倍になりクロックも。18 CUs 800MHzから 36 CUs 911MHz。4.2TFLOPS。
CPUは多少強くなったところでGPUが2倍以上で大幅増強。これは今後問題になりそうですが、発売日は今年内で十分攻めの姿勢を見せた。PSVRとほぼ同時発売はよく頑張ったな。
ScorpioはCPU、GPUともに1.5倍程度という違いが出てるけど、丸々一年遅くなることになりそうで痛い。
以下、ニュースリリース転載
為了完全發揮出A8N-SLI Deluxe的實力，長久以來都企圖想要達成"全SATA化"，但是最後總是無法跨越的藩籬－Sil3114晶片的相容性問題，終於找到解答了。
簡單講，Windows是靠inf檔來辨識Driver的。
所以即使晶片相同，裡面也有可能有一些User並不清楚的狀況，造成相容性問題。
3114的Driver就算是頗典型的狀況：
手邊的A8N-SLI Deluxe上面附的3114，ID為SUBSYS_81671043
(請由硬體管理員的[內容]–>[詳細資料]–>[硬體識別碼]來查看)，但是ASUS在網頁上讓人下載的Driver(1.1.0.0)則沒有內含這個ID，其他IHV(如Gigabyte等)的產品即使有使用3114，Driver內的ID也大多有些落差。
那麼，不顧ID能不能使用呢？
很可惜地，不行，安裝之後會hang在Loading Windows….
最後，在WindowsUpdate找到了可以使用的Driver(9234973.cab)，包含了相當多不同版本的ID….安裝之後也的確可以使用，順利地進入Windows了。
該版Driver的內容請參閱下列連結：
http://www.download.windowsupdate.com/msdownload/update/v3/static/rtf/drivers/9234973.htm
下載則需要前往Windows Catalog：
http://v4.windowsupdate.microsoft.com/catalog/zhtw/
接著，有一個相當值得注意的地方：
3114的特性，是必須在其BIOS內，將各個獨立的HD都設成JBOD(Single)，才能夠讓Windows讀到磁碟….
安裝適合的Driver，以及設好JBOD之後，就可以順利使用了。
話說因為單顆做JBOD與原來的讀寫並沒有任何不同，所以也可以與以前相同地任意插拔改變順序，資料並不會流失。
因為P2P Disk Crash的關係，停掉了一些動作，所以趁現在剛好關機測硬體….
以下是剛剛的一些心得。
1. A8N-SLI Deluxe 和 IBM SK-8805 Rapid Access III 的相容性問題
BIOS 1006。
因為SK-8805有內建的HSB Hub，所以晶片的Timing可能有問題，於是(限定)第一次啟動電源抓不到，
拔下來重插可以解決，不過不太方便….最後用隔個USB 1.1 Hub來處理它。
造成NF4 USB相容性扣分。
SK-8805的產品資料：
http://www-1.ibm.com/support/docview.wss?rs=0&uid=psg1MIGR-4V4QVC&loc=zh_TW
2. 6600GT SLI無法啟動
這個完全不知道怎麼回事，ASUS A8N-SLI Deluxe 和ASUS自己的NX6600GT SLI居然開不起來？
Driver 71.84，BIOS 1006。
裝完Driver之後閃兩下就BSOD掛掉，再重新開機進去也是BSOD，
兩次都顯示nv_disp.dll掛點，目前放棄中….
[EDIT：單張也會掛掉….所以現在頭很痛]
看來和SLI還是無緣…._A_
最後總共救回500MB。(死)
而且救回來的部份壓縮檔有些還是死的….
只能說那次chkdsk狂砍90GB真的太傷了….
當時應該當機立斷的啊….orz
人家死過當經驗，自己死過當教訓。
啊～好痛。
總之，至少Share恢復了。
—-
話說資料救援….
FinalData動不動就Raw Scan Mode上，所以都會找出老資料
Easy Recovery可以選模式，速度也比較快，但是成果也不怎麼樣
ZAR32…. Makoto推薦的，說起來介面很不友善。
不讀label對損毀的磁碟而言的確是個方法，問題是剛好系統上有同大小的硬碟的時候怎麼辦….orz
P2P Disk，WD 120GB檔案系統損毀。
近來的第三顆硬碟crash，目前orz中。
視為連串性的相關事件，如果完全沒救到的話，總損失量將上探200GB….
不過這回有盡可能維持住可以讓FinalData發揮的環境…..看看有沒有機會吧。
好，幾個澄清。
1. RAID對檔案系統Crash沒用
RAID只能預防實體硬碟損壞
2. 資料拯救軟體只對檔案系統crash有用
所以實體硬碟損壞的話，資料拯救軟體無解
3. 硬碟Offline，過熱等等也可能造成資料錯亂
照樣會成為檔案系統損壞的肇因，這個也和controler的Driver有關，
尤其是offline，可能File Table就整個不見了….相信是最大的資料損失原因
4. Fragment本身只對效能有影響
比方說Linux的幾個主要檔案系統(ext2、ext3、ReisterFS等)，
根本就不存在Defragment Solution。
—-
回到拯救狀況。
遭Windows chkdsk摧殘之後讓狀況複雜許多，FinalData用Raw Scan再度"挖"出了大量舊檔案；
Easy Recovery Pro雖然掃描速度很快，但是並沒有救回太多….
總之，如果HDD offline的話，一看到錯誤就別再動硬碟，包含reboot都盡量避免….
然後在這種狀況執行資料救援軟體，效果才會好。
即使是磁區看起來完全沒有東西的狀況，也大多只是table毀壞，
看得到硬碟就有希望…. 然後就是慢慢來了。