Esplora i link spaziali dei Tutorial RGH fatti con le mie manine Sante
«L'abitudine e' in tutte le cose il miglior maestro.» -- Plinio il vecchio, "Storia naturale"
Hahaha OK va bene vorrà dire che andrò ad esiliarmi in un monastero cinese tornerò quando sarò spiritualmente "degno di risposta"...
Dannata potenza di calcolo!!
La Panerai è una tipa mmmmolto spinta
Grazie sparco per avermi illuminato, però devo ammettere di non averla mai sentita questa, googlando invece ecco cos'ho trovato xD
sempre da 15432 ...... some improvement to increase stability
[url]https://www.dropbox.com/s/uv5pqb5bll9oszj/xell_wbx6.rar[/url]
No no panerai è una ****ostar toscana
Bah, io non direi. Proviamo a fare il punto della situazione. Fin'ora per glitchare è sempre stato utilizzato un "CB_B 13121" che però non contiene il corretto codice che inizializza le ram winbond da cui, fin'ora, nasceva il tristemente noto crash di sistema...
Dunque in soldoni è stato utilizzato un CB_B 13182 patchato di tutte le contromisure antiglitch che contiene (ricordate che dal kernel 15572 sono stati rilasciati CB_B>13121 che fino a questa nuova revision hardware con winbond non aveva senso utilizzare).
Da cosa nasce questa speculazione? Beh, provate semplicemente a guardare il contenuto di questo nuovo ecc winbond compatibile:
Immaginate che lavorone devono aver fatto!
1) I CB_B antiglitch non hanno POSTOUT!
2) Per fare debug avranno utilizzato code injection con post sentinella, immaginate con quale lentezza (e passione) siano andati avanti
3) Pur sopperendo quindi alla mancanza di POSTOUT ci sarà stata una geniale capacità di lavoro in ASM andando a spulciare la marea di registri che potevano causare il crash nel caricamento del CD ed una volta trovati, saranno stati patchati a regola d'arte.
Qualche vecchia comare, potrebbe obiettare che la mia speculazione è sbagliata in quanto l'header del CB_B utilizzato è facilmente modificabile....
A stima di chi ha lavorato alla soluzione di cui oggi godiamo GRATIS va detto che la differenza tra "il solito" patching del 13121" ed un "PATCHING DA ZERO del CB_B 13182 CON ANNESSA SOLUZIONE ANTISCHIANTO DEL CD" è davvero abissale.
Tanto per zittire queste male lingue, un diff di esempio è alla portata di tutti:
Questa volta, chi doveva vedere, non ci ha visto bene....
Ultima modifica di MamaMilk; 09-08-14 alle 17: 08
Si glitcha il CBA,che essendo un 9188 ha i POST CODE,ed essendo un CB zeropaired nn utilizza la cpukey per decryptare il CBB,quindi nn c'e' il problema del cryptaggio diverso dei CBB post 14xxx
Avranno applicato le solite patch a sto CBB 13182 e magari ritoccato qualcosina
Sn stati molto bravi
[URL="calciomonamour.altervista.org"]CLICCAMI [/URL]
Ultima modifica di MamaMilk; 09-08-14 alle 17: 20
MamaMilk, yes, that's fully patched 13182. Adding the 0x20 post and applying default patches was not so hard, but there was something else, not easy to solve. Try to find that patch
You and your friend are my new idols! I take a look at the final part of the diff (i'm sure TX also...) and the raw simplicity is sometimes the best way to solve problems. I am not referring to the entire huge work of patching but I think the address in Ram of the CD was a ugly beast! so i see %r3 and %r6 lost the correct address and with a big little luck, manually raw patching the correct address solve the problem.
Great respect and really thanks for the work done!
Ultima modifica di MamaMilk; 09-08-14 alle 18: 18
Si continua qui
[url]http://www.consoleopen.com/forum/news-xbox-360-e-xbox-360-one/19715-corona-con-ram-winbond-2kb-tutti-gli-aggiornamenti.html[/url]
Segnalibri