Como trabaja un modBIOS (TM XD)

Bueno, todo sabeis que el procesador tiene un bus de datos y otro de direcciones para comunicarse con los diversos dispositivos. Ademas de eso, el procesador tiene una señal para indicar que quiere leer y otra para escribir dentro del dispositivo, tambien tiene otra que indica al dispositivo que debe hacerle caso . Pero hay un problema: el procesador puede ser mas rapido que el dispositivo que quiere acceder, asi que para solucionarlo, existe otra señal especial que activan los dispositivos para indicar al procesador que debe detenerse, congelando todas sus operaciones, hasta que el dispositivo termina de leer o escribir el dato, momento en que libera al procesador para que siga con su tarea. Tambien existe una circuiteria de control del dispositivo: ella se encarga de parar al procesador, si es necesario y es la encargada de averiguar si realmente el procesador esta accediendo a ese dispositivo. Con estas señales, estamos listos para explicar el funcionamiento de los modBIOS

La utilidad del modBIOS es hacerle creer a la PS2 que los datos que hay en la BIOS son otros y con ello hacer que la proteccion de los discos, caiga. Para ello, lo que debemos hacer es esperar a que la PS2 acceda a la BIOS, en ese momento la circuiteria de control, detecta en la parte alta del bus de direcciones que intentamos acceder a la BIOS (tambien necesita la señal de control, que habilita al dispositivo) y entonces envia una señal de habilitar chip, que junto con la señal de leer y la parte baja del bus de direcciones, le dicen a la BIOS la direccion a leer. Entonces la BIOS (que es una memoria) escribe el dato en el bus de datos, claro, pero para entonces, nosotros enviamos la señal de parar al procesador. Al hacerlo, este se queda parado con todos su buses activos y nosotros podemos leer tranquilamente el contenido del bus de direcciones y escribir si es necesario despues que lo haya echo la BIOS (*). Entonces liberamos la señal de parada y el procesador ejecuta los datos que le hayamos escrito. Pero esto tiene el inconveniente de que tenemos que tener al menos 8 cables para el bus de datos y puede que 18 o mas para las direcciones, ademas de las señales de control y todo eso. Entonces ¿se puede hacer que un chip emplee menos cables para hacer esto?¿No dicen que el Messiash usa solo 16?.. Pues la respuesta es que si, pero con un truco. Imaginaros que os vendan los ojos y os meten dentro de una casa, os quitan la venda y os preguntan la direccion del domicilio en que estais ¿como lo podriais saber? Pues evidentemente, si conoceis la casa, reconocereis la decoracion y todo eso y sabreis donde esta esa casa. Lo mismo se puede aplicar en el caso del modBIOS: no usamos el bus de direcciones, pero estamos todo el rato pendiente del bus de datos y cuando detectamos que este envia una serie de bytes que son unicos a la rutina que queremos modificar, podemos escribir los datos pertinentes, para llevar a cabo la modificacion. Eso significa que si entre medias hay un bucle, tenemos que repetir las instrucciones, tantas veces como se ejecute el bucle (es decir tendremos que tener un conocimiento previo, de lo que hay que enviar y como). Por supuesto, para que todo funcione, la secuencia que elijamos para detectar la direccion en que estamos, no debe repetirse en otro sitio, o esto fallara.

Antes he puesto un signo (*) en el comentario. La razon de esto es que como alguno se habra dado cuenta, si congelamos los buses cuando la BIOS esta mandando el dato, no se liberara hasta que dejemos trabajar al procesador. La razon de esto es que como las señales de control, son activas a '0', no podemos revertirlas (si mandamos un '1', seguira siendo '0' como explique al principio del hilo). Entonces estamos jodidos ¿como lo hacemos para poder escribir en el bus? Tenemos 3 opciones:

1) La primera, consiste en ignorar esto y escribir directamnete en el bus. Si lo hacemos asi, solo podremos borrar bits, lo que nos permite poder modificar algunas instrucciones, para que funcionen de otra manera o insertar la instruccion 'nop' (que no hace nada), para eliminar el codigo que consideremos inconveniente. El problema, es que a lo mejor con 'borrar' datos no es suficiente y que cortocircuitamos el bus de datos de la BIOS y no sabemos como le afectara eso.

2) La segunda, podria ser cortar la pista por la que envia el procesador la orden de habilitar dispositivo, al controlador de la BIOS o la señal que envia este controlador a la BIOS para habilitarla. En su lugar, pondriamos una puerta OR, que nos permitiria controlar desde el mod, cuando damos libertad al procesador para acceder a la BIOS y cuando lo prohibimos (y en su lugar escribimos nosotros el dato). Esta creo que es la mejor opcion, pero no creo que sea la que 'ellos' utilizaen.

3) La ultima alternativa, consistiria en que como no podemos engañar al controlador de la BIOS, con la señal de seleccion procedente del procesador, porque esta a '0', tal vez podemos engañarle con las direcciones. Me explico. El controlador, debe decodificar la parte alta del bus de direcciones y tener encuenta la señal de seleccion, para enviar una señal propia de seleccion a la BIOS. Entonces si cambiamos de valor uno o varios de los bits de direcciones, de esa parte alta, automaticamente dejara de seleccionarse la BIOS (que truco). Para que funcione, tiene que ser un bit que este a '1' y nosotros ponerle a '0' y la direccion que genere, debe estar desocupada, es decir, que no haya ningun dispositivo alli. Como siempre un problema: en este caso estamos cortocircuitando unas señales procedentes del procesador.

La primera conclusion que sacamos, es que salvo que se corte la pista que sirve para habilitar la bios, solo podemos cambiar las señales por mezcla (en un caso afectaria al bus de datos del chip de la BIOS y en otro algunas lineas de direcciones del procesador). En ese caso, todo dependera de lo bien que soporte el exceso de corriente tanto la BIOS, como el mod o el procesador. Habria que recordar que los chip cuanto mas rapidos, menos corriente necesitan y por tanto, menos corriente soportaran (y menos calor).Eso quiere decir que con un tiempo ridiculo de exposicion, podrian resultar dañados a medio plazo y es lo que me preocupa. Tambien hemos visto que la forma de funcionar de esto (cambiando un dato por otro), hace que las distintas versiones de la BIOS, puedan afectar seriamente al funcionamiento del chip y ya no digamos una actualizacion que vaya directamente a por el. Para solucionarlo, tendriamos que tener la opcion de poder 'upgradear' el chip mediante alguna forma y tambien deberia darse cuenta el chip de que el entorno ha cambiado (que no tenemos los mismos datos en la bios) y automaticamente desconectarse o ponerse en espera para actualizar. Hay muchas probabilidades de que la BIOS, que es un chip medio-rapido, sea copiado en la memoria RAM (como espejo), para que no sea un 'lastre' para el procesador, a la hora de trabajar con ella. Si esto es asi, el chip que podria llevar a cabo el proceso de cambio, no tendria porque ser muy rapido, ya que el tiempo que tardase no seria tan critico. En caso de que esto no sea asi, deberiamos tener cuidado de que los bytes a modificar no estuviesen en medio de una rutina que tiene que ejecutarse muy rapidamente, o todo fallara por esto. El numero de cables dependera de lo que hagamos: Si usamos todo el espacio de direcciones, mas datos y control, podria andar sobre los cuarenta cables. En el caso de tener que reescribir las rutinas usando el truco de leer del bus de datos para reducir cables, podria estar en los 16 del Messiash., pero si solo borrasemos (mediante 'nop') los datos, con 13 podrian bastar.

Bueno, solo quería "discutir" un poco contigo un tema...
Verás, comentas todo el rato q el procesador tiene una señal para detenerlo, kedando congelado. Sin embargo, a riesgo de meter la pata (tú eres el maestro y si lo dices será por algo ), yo diría q tal señal no existe. Los procesadores están ejectuando instrucción tras instrucción continuamente, y aunq algunos incluyen en su juego de instrucciones una instrucción para "congelar" el procesador (halt), ésto solo se hace a nivel de software y no podría ejecutarse con una simple señal q mandara el chip.
Normalmente, como sabes la comunicación con los dispositivos se realiza mediante interrupciones, de modo q cuando el dispositivo está listo le manda una interrupción al procesador para q este le atienda, y mientras tanto el microprocesador va haciendo otro trabajo, pero no se keda parado...

Pues yo estoy más de acuerdo con Jixo que con USB.

Si no me equivoco los procesadores actuales están diseñados y trabajan de manera concurrente, compaginando diferentes procesos.

De esta manera, se aprovecha los estados de entrada/salida de un proceso (se dice que el proceso está bloqueado) para trabajar sobre otro proceso, haciendo así que la CPU esté menos tiempo ociosa y aprovechándola al 100%.

No tiene demasiado sentido tener un procesador extremadamente potente (no hablo sólo del EE y/o el IOP) y luego pararlo cada vez que necesita un dato.

Saludos.

Vamos a ver. Lo primero que hay que decir es que esto es una forma 'simple' de describir el proceso. Esta dirigido a que se entienda como trabaja el dispositivo, pero logicamente dependera del diseño del procesador. Las señales no tienen porque funcionar exactamente asi, pero he estado mirando el PDF del r4000 (equivalente a r3000 en señales por ejemplo) y resulta que tiene una señal (EB_ARdy) con la que un dispositivo externo le indica a la CPU, que no esta preparado para recibir todavia, y durante ese tiempo, la CPU no envia nuevas direcciones, asi que aunque no se haga una congelacion de los buses realmente (como en procesadores mas antiguos), mientras esa señal este asi, el procesador no hace nada (salvo procesos que no tengan que ver con dispositivos). En este caso, deberiamos activar tambien la señal EB_RBErr, que le indica a la CPU que ha habido un error de transaccion (con el fin de que no tome porvalido el valor de la BIOS) y luego poner a nivel alto EB_ARdy y transferir el valor del mod (la señal de seleccion seria EB_AValid en este caso) . Tampoco se ha tenido en cuenta que todas estas operaciones, estaran dirigidas seguramente por un chip que controla los buses y que es el que se encarga de comunicar los dispositivos con la CPU. En cualquier caso, la CPU no puede ejecutar ningun proceso, porque se queda esperando al dispositivo externo (no habeis tenido en cuenta, que esto no tiene que durar toda la vida, aunque segun he visto en el PDF, podria hacerse porque no tiene limitacion, como otros. Seria muy dificil de apreciar y ¿por que creeis que digo que es posible que se copia en RAM la BIOS? Por cierto, el PC hace lo mismo).
La idea era explicar de una forma sencilla, para que lo entienda la gente y la forma en que yo veo el problema, no diseñar el chip ahora mismo para el procesador de mips. Por cierto, el origa chip, no tiene reloj externo (creo, que a lo mejor lo pilla de la placa), afecta a la BIOS y es posible que funcione a una frecuencia muy baja (desde luego, no la del emotion engine) ¿como se sincronizaria, si no?

O algo no he entendio, USB, o no estás teniendo en cuenta que para operaciones de entrada/salida la Playstation 2 utiliza un R3000 independiente. Por lo que el procesador puede estar haciendo maravillas mientras el IOP se encarga de todo lo demás.

Creo que lo estás planteando como si el EE fuera el único procesador que posee la PS2, mientras que tiene unos cuantos.

Saludos.

Joer..., me estoy empezando a cansar del hilo . Vamos a ver, lo primero que tenemos que entender, es que nadie de nosotros tiene todos los datos sobre el funcionamiento de PS2 (y si no, pasarme los esquemas, descripcion de señales con sus correspondientes patillas (o al reves ) y la BIOS capturada!).
En fin, la descripcion que yo hice, es bastante generica, una forma de entender las cosas, sin tener que explicar al detalle el funcionamiento interno de la consola (si supiera todo eso, o sacaba yo el Messiash o directamente diria: no lo pongais o adelante con ello.

Lo primero que tenemos que entender, es que cualquier procesador, esta preparado para acceder a dispositivos mas lentos... y eso significa que en un momento dado, debe frenarse (de ahi los cuellos de botella).

Lo segundo es que delante del procesador/procesadores de la PS2, hay un chip que controla los accesos. Ten en cuenta que la BIOS parece que tiene un bus de datos de 8 bits y los accesos del r3000 son de 32 bits y los de r5900 a 128 bits, asi que como ves, en realidad no le decimos al procesador que se pare, si no que se le dice al controlador del bus y este al procesador.

Tambien me parece logico que de la BIOS se encargue el r3000, al fin y al cabo, controla todos los accesos I/O y la BIOS es la capa que controla I/O.

Dicho asi, parece logico que primero arranque el r3000 y prepare el camino para el r5900, antes de llamarle, asi que el control hay que hacerlo sobre el r3000 (eso me parece a mi).

Como los accesos a la BIOS (datos), son de 8 bits, parece logico que se carguen en RAM para accesos a 32 bits.

Como el Origa u otro chip, tienen que procesar informacion antes de enviarla, parece logico que actue sobre una señal o dos, para hacer que la CPU espere a que termine su 'trabajo' ( o si no, trabajar a 300Mhz, para que le de tiempo).

Si estamos 'bloqueando' el r3000 y el combinado r3000/r5900 usa un doble bus (que parece muy logico para evitar esperas innecesarias, lo que este haciendo el r5900, no nos incumbe y nos trae sin cuidado. A nosotros lo que nos interesa es que el procesador que este accediendo a la BIOS, espere a que pongamos el dato correcto.

En efecto, la PS2 tiene procesadores, microcontroladores y chips varios, pero solo uno lee la BIOS y es sobre ese, sobre el que hay que actuar.

Una cosa mas, todos los procesadores tienen señales de control y algunas son iguales y otras se asemejan. Solo hay que encontrar cual es mas conveniente y si no viene del procesador, viene de un controlador asociado a el para realizar las operaciones y en este si tendremos esa señal de control. Si no, no hay manera de acceder a dispositivos lentos (y para muestra un PC cualquiera).

P.D: La clave esta en el IOP: el se encarga de las funciones basicas y proporcionar el entorno al EE. El hecho de que cargue la PS2 un disco de PSX, asi lo demuestra tambien: automaticamente el IOP, carga un programa en el EE para emular el video y bloquea los accesos y despues sigue con su tema. El EE es una marioneta en manos del IOP, que esta para servirle, pero que tambien, curiosamente, le controla.

Bueno, como dices ninguno de nosotros sabe cómo funciona realmente la ps2, y mucho menos el chip! Pero eso de q el chip "detenga" al procesador y modifique sus datos no me parece muy convincente... Mi teoría es q nada más encender la consola, el chip en algún momento modifica el código de la bios (seguramente cargado en la ram como dices), parcheando las rutinas necesarias, pero solo lo haría una vez. Aún así el proceso será mucho más complejo y habrá q tener en cuenta muchos otros factores. Una cosa curiosa es q creo q utilizarán el mismo mod para todas las versiones de las consolas, con lo q probablemente parchearán la bios de forma diferente según la versión de ésta.
Sobre lo de q Sony puede joder el chip en cualquier momento actualizando la bios no lo tengo yo tan claro... según creo cuando "actualizan" la bios (o más exactamente los drivers del dvd) lo q hacen es utilizar la memory card para guardar la nueva versión, no modificar la rom de la bios, con lo q la solución sería bastante sencilla . Por otro lado, la gente de channeltech parece muy confiada con la seguridad de su mod, y además están haciendo una gran inversión (hablaron de más de 100.000 unidades...). No creo q arriesgaran tanto si no estuvieran 100% seguros.
Espero tu respuesta, y no te canses de este hilo hombre, q me gusta "discutir" un poco contigo

PD: El procesador de un PC no se detiene nunca para esperar a un dispositivo, al menos de la forma q tú comentas -con una señal por hardware-. Todo el tema del control de los dispositivos lo manejan los drivers y el SO, y la pobre CPU no para ni un naosegundo, aunq esté haciendo un "while (1);"

jiXo, esta claro que solo se parchearia una vez la BIOS, pero para hacerlo hay que sincronizar la lectura de la CPU con la escritura que hace el modBIOS. Ya has visto que existen señales para DETENER al procesador (mira en mi post de madrugada, EB_ARdy si esta señal se hace 0 el procesador no puede generar nuevas direcciones, luego se para.

Tampoco estoy de acuerdo con lo que dices del PC. Si yo pongo esta orden en C a=inp(0x379), estoy leyendo el puerto de impresora, que en el mejor de los casos no puede superar los 8 Mhz, asi que tu me diras como lo haces. Otra cosa ¿porque cuando imprimo un documento mi PC se enlentece?. Si sigues sin convencerte ¿porque cuando hago un test sobre memoria de video, no es igual que sobre la RAM? ¿porque han eliminado mi querido BUS ISA. Creo que no acabais de coger como funcionan las CPU a nivel electronico. Vosotros pensais que la CPU se puede poner a hacer otra cosa mientra espera a recibir respuesta de la inp(0x379), pero ¿como lo va a hacer, si yo envio una señal que le indica a la CPU que espere a que este listo? No se puede usar el bus, en ese momento. Desgraciadamente, es asi como ocurre: cuando la CPU accede al bus PCI, lee/escribe a 33Mhz y si es a ISA a 16Mhz como maximo.

Lo que si puede hacer la CPU es mientras espera la respuesta, preprocesar las siguientes instrucciones.

Lo que ayuda a que no pare el procesador, son las DMA. Cualquier proceso de DMA, permite transferencias entre un dispositivo y la memoria directamente, pero incluso asi hay problemas: Imaginate que la CPU y una DMA se encuentran accediendo al mismo bloque de memoria y esta DMA es critica y no debe interrumpirse ¿sabes lo que hace? le para los pies al procesador y solo cuando ha teminado su ciclo de escritura, le deja actuar. Sin embargo el tiempo que tarda esto, no es normalmente significativo, por lo que no nos damos cuenta de que nuestro procesador, de vez en cuandoo, deja de procesar.

Primero el bus entre el IOP y la bios es de 16 bits no de 8 como decia USB


USB se está acercando, el meollo no está en el IOP, si no en el DMAC(DMA Controller).

Todas las comunicaciones de datos en la PS2 se realizan por DMA y controladas por el DMAC. Para ello utiliza una serie de tag que identifican los extremos de la comunicación, tipo de datos a transferir, modo de transferencia ademas de canales DMA, etc.


El IOP por si sólo no actua, el sólo se va comunicar con los perifericos incluida la bios al iniciar la maquina. Pero la comunicacion de esos datos se controla con el DMAC y no hay una conexión directa entre el IOP y el EE para ello está el SIF que hace de interfaz entre ambos. Es decir que no hay una comunicación directa entre IOP y EE se realiza toda a traves de este interfaz y además controlada por el DMAC.

El IOP y el EE tienen su propio kernel cuando arrancas ambos cargan su kernel y el EE le dice al IOP que cargue los driver (modulos irx) necesarios para que se comunique con el lector. Si por ejemplo, metes un disco de PS1 al final el que detecta si es valido es el EE. Si el EE detecta que es un disco de PS1 le dice al IOP que resetee a modo PS1 y él (no el IOP) empieza su emulador de GPU de PS1. Una vez hecho esto ya puede empezar a cargar el disco de PS1 en este caso el que finalmente el ejecute la aplicacion será el IOP. Cuando introducimos uno de PS2 despues de identificar el EE su validez le dirá al iop que le pase todo lo que lea del lector y el propio EE ejecutará la aplicación. Siempre que el EE necesite acceder a algun periferico se lo cumunicará al IOP mediante la correspondiente trasnferencia DMA entre EE y SIF.

Y de paso la PS2 si usa interrupciones

dos tipos

INT0 para interrupciones provenientes de los dispositivos

INT1 para las provenientes del DMAC


Bueno a seguir bien

Salu2

Bigboss, no dudo de tu palabra en esto que has dicho, que me parece muy interesante (al fin y alcabo, tu tienes mas datos que yo sobre el funcionamiento de PS2), pero hay una cosa que no me queda claro: si el bus de datos de la BIOS es de 16 bits ¿como demonios se puede montar un chip con 16 hilos? (es imposible), a no ser que sea la comunicacion entre IOP y BIOS pase por otro chip, que realice la adaptacion o que el IOP admita transferencias de ocho bits.
Lo que esta claro es una cosa: si tienes razon en todo, entonces los ce channel han engañado a la gente al decir que con 16 cables se podia montar el chip, luego si mienten en eso ¿en que mas?

jiXo, antes no te he respondido a eso que decias del la actualizacion de la BIOS. Lo primero, no creo que estos tios esten seguros al cien por cien de que no haya 'vacuna' contra el chip. Que fabriquen 100000 unidades, no es muy relevante, teniendo en cuenta que se decia que hay que hacer un desembolso de 2500000, para distribuir el chip. Yo creo que si SONY puede actualizar la BIOS, lo tiene muy facil para cargarse ese chip, lo que pasa es que ese codigo 'asesino' solo podria venir en las unidades de PS2 nuevas y en los DVD nuevos (podria venir incluso en las Demos). Si usa la tarjeta de memoria, es lo de menos, pero ¿que tal si un juego no carga si no esta actualizada la BIOS a tal version? (cosa que podria hacer el juego), por supuesto que eso podria evitarse 'parcheandose' el juego, pero ya podria ser demasiado tarde: miles de consolas podrian dejar de funcionar, ademas, habria que encontrar el parche. Habra que esperar como 'contraataca' SONY y ver tambien lo equivocado que estoy en lo referente a las posibles 'averias' (espero por vuestro bien, que equivocado del todo)

Es en el SIF donde se forman los paquetes de datos. Internamente tiene una cola bidireccional SFIFO. El DMAC de la parte del IOP lee del espacio de direcciones de memoria del IOP y el DMAC de la parte del EE manda los datos a espacio de direcciones del EE.

En las tags que te dije antes vienen definidas esas cosas fuente, destino y tamaño de datos, etc.

Los paquetes que forma el SIF son de qword( 128 bits) y el bus con el EE es de 128 y con el IOP de 32 obviamente



casi na y eso que no me he hablao na del vu1, vu0 y gs que eso ya es otro cantar.


Salu2

has repetio el post o yo toy flipando a estas horas de la noche



Salu2

Bigboss deja la bebida XD;)XDXD

Bueno, mi turno (q aunq sea el q menos sabe tb tengo derecho a hablar XD)

>sobre la actualización de la bios:
Bueno, el tema está en q podrían cambiar la bios en nuevas versiones de la consola, pero creo q solo sería cuestión de tiempo q sacaran una nueva versión del chip para ellas.
Sobre q un juego no cargue si no está actualizada tal versión de la bios no lo veo demasiado factible... lo primero es q obligatoriamente se necesitaría una memory card, la cual no viene de serie en la consola, así q no pueden obligar a todos los usuarios a tenerla. Luego está lo q comentas de los parches, pasaría igual q con los primeros juegos de psx con protección antimod, pero de nuevo creo q no sería muy comercial para los desarrolladores vender un juego q no podrá ser usado (original) en la mayoría -o en muchas- de las consolas...

>Sobre la comunicación de la cpu del pc con los dispositivos:
Vamos a ver, los dispositivos se atienden a nivel software y no hardware, y son los drivers los q controlan la comunicación. Cuando un proceso quiere leer o escribir en algún dispositivo, hace una petición de entrada/salida, y si la comunicación no es posible se queda en estado bloqueado esperando q éste mande una interrupción, mientrastanto el planificador de procesos del SO le da la CPU a otro proceso para q siga trabajando, pero ésta nunca se queda parada. Esto es lo q ocurre si lees del puerto de impresora como comentas, y aunq para ese proceso la CPU haya estado congelada, en la realidad ha estado atendiendo a otros procesos.
Si estuvieramos en un sitema monotarea del año de mariacastaña, cuando tú ejecutaras "a=inp(0x379)" para leer de la impresora, dependiendo como estuviera implementado a nivel software (a nivel del compilador o de la bios), la cpu haría una cosa diferente, pero probablemente estuviera leyendo continuamente del puerto con un bucle, hasta q cambiara la señal q indicara un nuevo dato.
Y bueno, solo comentarte q todo esto no me lo he inventado, es más o menos lo q recuerdo de asignaturas como Estructura de computadores o Sistemas Operativos

jiXo,jiXo has vuelto a enfocarlo otra vez por software . Te lo voy a explicar mas claro: supon que tu procesador trabaja a 3ns como el mio y estas accediendo a un dispositivo que necesita que mantengas la señal durante 100ns para que se entere que te esta dirigiendo a el ¿lo vas cogiendo? El SO no puede dar acceso a otro tarea porque el BUS necesita mantener la direccion todo ese tiempo. Yo no estoy hablando de una impresora que esta ocupada que se detecta por software, estoy hablando de un dispositivo que funciona a otra frecuencia y que necesita que estemos pendiente de el y que tampoco supone mucho tiempo como para dar acceso a otra tarea. Esa son las pausas que se hacen por hardware y aqui el SO no pincha ni corta, porque no es un tema de comunicacion con el dispositivo, si no de acceso lento

No sé, quizás lo esté enfocando demasiado por el lado del software, pero da lo mismo, te aseguro q la cpu no está NUNCA parada con un sistema windows (Linux sí q utiliza la instrucción halt cuando no hay ningún proceso q ejecutar).
El problema es q todo el hardware de un ordenador es mucho más complejo de lo q comentas, la cpu solo usa el bus para leer o escribir de la memoria cache, y todos los demás dispositivos y buses se controlan a través de los diferentes controladores q lleva la placa base.
De todas formas mañana buscaré de entre mis viejos apuntes y te lo intentaré explicar todo mejor, a ver si consigo convencerte (aunq sé q no lo haré, pq si Savage no pudo contigo... )

Ten encuenta que de estas pequeñas paradas no se entera el SO. Ya se que todo es mas complejo de lo que comentamos aqui, pero todos los dispositivos a los que accede la CPU son mas lentos que ella, asi que necesita un mecanismo para ponerse a la altura de ellos. Te aseguro que normalemente no se nota mucho. Por cierto, esa es la razon de que las CPU tengan caches para acceder a memoria: para evitar en la medida de lo posible tener que leer directamente de la memoria principal (mucho mas lenta). Por eso si saltamos, provocando que se vacie la memoria cache, el procesador va mas lento que si esta dentro de esa memoria (por ejemplo: cache de primer nivel a 3ns, de segundo nivel a 5ns y memoria principal a 10ns, aqui no tienes escapatoria, claramente se ralentiza el procesador si se sale de las caches)

Hay una cosa que es cierta: que los procesadores cada vez cubren mejor sus defectos, tanto, que cuesta encontrar un ejemplo convincente que ilustre que en realidad hay señales que sirven para sincronizar los datos y que eso significa frenar a la CPU (cada vez ocurre menos a menudo).

Has vuelto a nombrar halt. Este tipos de instruccion (wait en otros) lo que hace es que para el procesador en espera de una interrupcion (produce una señal externa que indica que esta esperando el procesador la interrupcion) y no es lo que yo digo

NOTA: No se en que sentido dices lo de que mi 'hermano' Savage no pudo conmigo.... si lo dices por lo del sampleo, creo que quedo claro a lo que me referia (que una señal aparentemente continua, podria ser de frecuencia igual o multiplo de la de muestreo. o sea que si muestreo a 44khz una señal de 44 Khz, parece continua pero no lo es). Quiza sea eso lo que me diferencia de otra gente, que me gusta ver las cosas de otra perspectiva

NOTA2: Savage, vuelve, que ya es hora (aunque sea para ponerte en el bando enemigo )

Bueno, aún no he buscado los apuntes q quería, pero poco a poco nos vamos aproximando... Está claro q el procesador va mucho más rápido q todos los demás dispositivos, y q éstos son un cuello de botella, con lo q frenan el rendimiento del PC, pero lo q yo digo y redigo es q la CPU no se queda nunca congelada manteniendo todas sus señales costantes, SIEMPRE está ejecutando algo, aunq sean NOPs...
Y si nombraba la instrucción HALT, es pq es la forma en la q se produce lo q comentabas (CPU congelada completamente, en espera de una señal q la despierte -interrupción-).

Nos leemos luego

Me está gustando este hilo, pero creo que debería centrarse de nuevo en la PS2, si queremos llegar a alguna conclusión sobre los chips que comentaba USB. Lo digo más que nada, porque la diferencia de arquitectura entre PC y PS2 hace que no todo lo que conozcamos del PC pueda estrapolarse a la consola.

Saludos.

Pues la verdad q sí, creo q lo mejor sería separar este hilo en dos, uno con la temática original, y el otro con el USB vs jiXo
Por cierto, a ver si BigBoss nos da su idea del funcionamiento de los "modBios", con más detalles de lujo

Pues Jixo, a ver si repasas, si puedes, el perfil de usuario de Bigboss, porque me comentó anoche que tenía problemas para postear desde que modificó alguna opción de su perfil.

Supongo que cuando me dijo eso, sería porque algo tendría que decir.

Saludos.

Eso, eso, que Bigboss cuente mas cosas . Ya sabeis que lo que yo dije, es una aproximacion a como puede funcionar, pero yo no conozco la arquitectura de la PS2. Si alguien tiene documentos sobre esto (sobre las señales y por donde pasan), seria interesante conocer como funcionan. Diria mas, si alguien sabe como, podemos cargar elf y algunos detalles mas sobre la carga (yo hasta ahora especulo con lo que observo, pero nadie me da datos asi que puedo estar malgastando el tiempo toda la vida) podriamos hacer un pequeño codigo que sirviera de cargador de los juegos, tanto desde el demo CD, como desde una demo en DVD, para usarlos como BootCD.

Por cierto Bigboss, espero que no te moleste la pequeña broma de mas arriba, pero es que ayer por no se que motivo, se duplico el hilo de forma misteriosa y despues de borrarlo 3 veces seguidas en las que me decia que se habia realizado con exito, SEGUIA AHI (!) y fue cuando tu lo leiste.

Ayer estuve via MSN 'conversando' con Haute y me comento algo que la verdad, lleva bastante razon: Ya que el metodo EA, funciona tan bien y no parece molestar a la PS2 tanto, ¿no deberiamos hacer que todos los juegos entraran por ese metodo?

Por cierto, ya comente una vez que si supiera donde se localiza una de estas señales 'congeladoras', quizas se puedan hacer cosa que hasta ahora no podiamos.


jiXo, vamos a dejar el tema del PC ya: tienes razon en parte, por supuesto, ya dije mas arriba que la CPU en ese tiempo podria seguir procesando instrucciones que no hagan acceso a dispositivos (no cambios de tareas , que necesitan de acceso a memoria y consumen MUCHO tiempo, solo las instrucciones que tenga el pipeline o como mucho en la cache interna) . Si el tema esta pensado bien, mientras, podria esta recargandose la cache interna, por ejemplo, hasta que recibiera permiso del dispositivo. A lo que yo me refiero es que hay señales que paran un proceso en concreto, que estan pensadas para durar solo un instante, pero que si intervenimos nosotros, podriamos paralizar la ejecucion de instrucciones por parte del procesador.
Es decir, que el procesador no deja de 'latir' por ello y puede estar haciendo otras tareas de tipo interno (tu razon), pero que no podria seguir ejecutando instrucciones mientras no le demos permiso con las señales (mi razon). Estas señales estan ahi desde el principio de los tiempos, aunque han evolucionado por supuesto.
Lamento que a veces lo que digo os parezca demasiado 'simple'. Eso es por dos motivos: cuando uno quiere hacer entender algo, no se pueden hablar de cosas complicadas y que uno no tiene todos los datos (por eso decia ayer lo de 'cansarme' del hilo), se hablan de cosas sencillas y luego se adapta a la situacion y la segunda razon, es que yo solo he diseñado un 'ordenador' de 8 bit, hace tiempo (con un Z80 a 6Mhz) y una de las cosas que tenia este cacharro, era que podia programar eprom en uno de los bancos en el ciclo de escritura y para ello necesitaba 'congelar' la CPU con ayuda de un monoestable... (en fin lo dejo que me enrollo )
P.D: Ya sabeis que yo en estas cosas siempre me he considerado 'tuerto' y el 'tuerto' puede explicar cosas a los 'ciegos' pero poco mas

Aunque con to lo que dije lo mismo alguien pensará que si


Bueno este finde tendremos una sorpresita para todo aquel que le interese la programación para ps2 en LAPS2.


Y no no me ofendi por lo que me dijiste anoche USB xD faltaria más. Pero lo ves como tenía razón y no estaba flipando.

Ya veo que le pegas a todos los palos pc, ps2 Z80 dios que tiempos aquellos en donde el mejor ordenador de 8 bits que ha existido y existirá(el MSX por supuesto pese a quien pese) me hacia pasar los ratos con aquellos juegos japos que los pobrecitos del spectrum y del amstrad jamás soñaron ver en sus tristes maquinas, uy que se me va la olla xD.


Para jixo que no se enfade tas lento con lo del linux para ps2 siempre me adelanto pero es que juego con ventaja en ese tema

Estoy deacuerdo con Yogurth la arquitectura de la ps2 es muy diferente del PC y todo lo que se hable de pc no es valido para
PS2. Un poner:

el gs mismamente. Tenemos varias rutas para llegar a él. Ademas del gigantesco bus memoria gs - gs que tiene la friolera de 1024 bits de ida 1024 de vuelta mas 512 de texturas casi na

Creo que el meollo está en el DMAC es él quien controla todas las comunicaciones en los buses de la ps2.

bueno no me enrollo mas


Salu2 y atentos al finde

y no solo eso. Haber si adivinas quien acaba de montar un CD, con el PDX view, Xtreme y AR2 v1.9 (al parecer se necesita la secuencia Xtreme+AR2 para cargar DVD) todo ello con un simple swap de la demo (lastima que no tenga la 'llave' y un DVDr ). Lastima que no todo el mundo tenga ModchipX...

Está muy bien eso que cuentas USB, pero en el fondo tampoco debemos preocuparnos por ese tema si realmete los chips de los que se supone que se hablaba en este hilo (que está cambiando de tema demasiado ya) hacen lo que prometen. Podremos olvidarnos de swaps, boot CDs, parcheadores EA y todas esas "incomodidades".

Tengo un par de preguntas para ti, USB:

1- ¿Qué pinta el PDVIEW en ese CD?

2- En un hilo, hace tiempo, creo que leí un post tuyo en el que decías que algunos juegos habían actulizado la bios de tu ps2 o algún driver (no recuerdo exactamente que digiste). ¿Me puedes explicar en que consiste exactamente dicha modificación y que juegos son esos? (Si estoy confundido y no digiste nada de esto también me lo dices).

Esto último lo digo por saber si puede realmente afectar al funcionamiento del "biosmod".

Saludos.

Hola Yogourth. El pdxview, pinta lo que supones que pinta: para pasar ficheros elf y programar (se carga como la demo del SSX).

Lo de la actualizacion de la bios, al principio no me di cuenta: entonces alguien dijo por aqui que habia observado una actualizacion del driver de DVD con el formula one 2001 (y luego con el GT3) y me fije que yo tenia la misma version (y antes era la 1.20 que tenia)

Pues a ver... Yo tengo el driver del DVD en la memory card porque compré el mando oficial. También tengo el GT3 original y no me actualizó el driver, sigo con el que viene de serie (si saco la memory card, que es donde está el driver) el 1.20e . Esa actualización que tu comentas... ¿donde guarda el nuevo driver? ¿en la memory card o el la propia consola?

Si es en la misma consola, no veo pq el del mando a distancia lo hace en la memory card.

Saludos.

Mi ps2 es de las primeras, de las que hubo que hacer reserva en el lanzamiento y no ha entrado ni gt ni f1 y mi driver es el 1.20e o sea que es el que viene de serie con la ps2 al menos con la mia.


Otro punto interesante, para arrancar el linux en ps2 es necesario tener una imagen del kernel en la memory card. Cuando arrancas primero va al boot loader que tiene el dvd del linux pero al final siempre debe acceder a la memory card para arrancar ( aunque no tengas disco duro que es el caso de mi ps2 pal)


Salu2

Hola no se como lo he hecho pero tengo la version 1.30. He estado buscando por los hilos, para ver si encontraba al qu lo comento y Xesk_Malone en este hilo, dice que tiene la misma version que yo y no tiene el GT3


http://www.elotrolado.net/showthread.php?s=&threadid=20111&highlight=1.30

otro hilo:

http://www.elotrolado.net/showthread.php?s=&threadid=18112&highlight=1.30


ya dije, que yo oi un rumor, mire y lo tenia cambiado y supuse que seria de esos juegos pero quizas no (pudo venir en una demo? o puede ser que se actualize solo si hay espacio en la tarjeta de memoria?)

USB,

ahora que tienes una nueva V3 podrías estar al tanto de tus drivers DVD y así a ver si descubres cómo se te actualizaron de la 1.20 a la 1.30.

No es que sea importante, es por curiosidad.

Saludos.

Yogurth, estoy fuera de tarifa plana, pero como voy a tardar (tengo cosas que hacer) te contesto ahora. La nueva V3 que tengo, he probado alguna demo y por supuesto GT3 y F1, a ver si se actualizaba y sigo con 1.20. Tambien tengo la misma memory. Mi creencia es que a lo mejor, esa actualizacion se hace para corregir algun problema que afecta a algunas consolas (ya sabes que algunas no reproducian bien ciertos DVD's). Todos hablamos de V3 y V4 pero lo cierto es que hay pequeñas diferencias entre las consolas que pueden ser achacadas a usar componentes de distintos fabricantes o tal vez la calibracion del laser (por software) no es suficiente en algunas consolas y por eso lo corrigieron. Por curiosidad, mi nueva consola la desmonte casi por completo, para ver el Emotion Engine y el resto de las cosas. Hace cierto tiempo, estuve en una pagina donde se mencionaba que un chip de toshiba podia ser la BIOS. Solo hay un chip de toshiba, en formato dual-in-line que tiene toda la pinta de ser una memoria de tipo flash (etiquetada como F91428) pero este chip no figura entre los componentes que tiene toshiba en su pagina (le habran cambiado la numeracion) pero lo que si es cierto es que los que tienen que empiezan por F, son memorias flash que curiosamente pueden funcionar con un bus de 8 o 16 bits (16 para el acceso de IOP y 8 para el modBIOS?)
Lo de que los drivers se pongan en la memory (esos que dices tu), puede ser por falta de espacio. Las japonesas segun creo, tenian los drivers del DVD en la memory y sin embargo, nosotros los tenemos en la BIOS. Mi creencia es que SONY tiene la manera de parchear la BIOS por software, directamente, sin usar la memory (que seria peligroso) y por etapas, igual que podemos hacer en el PC, pero que Messiah por poner el ejemplo, puede anular la escritura (no permitiendo la tension de programacion), con lo que SONY no podria parchear la BIOS, pero a lo mejor los nuevos juegos, no funcionen si no se permite esto y que cueste un huevo de parchear. De todas formas, para que se tomen medidas de este tipo, hara falta bastante tiempo y a lo mejor no lo tienen tan facil. Otra cosa que yo veo, es que una actualizacion con mas funciones del DVD, puede estar en la memory, pero si son los driver de PS2, esta claro que ese no puede ser el camino a emplear, seria ridiculo. Conclusion: yo creo que pueden parchear directamente la BIOS, pero que ese acceso lo bloquean los nuevos chip y habra que ver que camino toma SONY. Eso si, la actualizacion de la forma que se haga, no te das ni cuenta de que se esta haciendo (yo no vi nada raro y me entere tarde ). Lo que no se es si a SONY le interesa este tipo de juego (no seria la primera vez y mas con XBOX y GC cerca)
De todas formas, seguire probando cosas.

OK, gracias.

Saludos.

Antes de nada felicitaros a todos porque este ha sido un hilo verdaderamente de un foro y buenisimo, habeis discutido como se ha de hacer y dando todos argumentos de peso...felicidades.
Por otro lado las ideas que me han quedado mas o menos claras son que lo del modbios no me parece una solucion factible y en todo caso si SONY pone cartas en el asunto, cosa que dudo si la XBox sale, puede capar estos modbios facilmente de multiples forma, creo recordar que alguien comento de que si esto se hacia se modificaria la programacion del modbios para solucionarlo, pero como lo van a hacer? tendran que abrir la consola sacar el chip programarlo, o enviarlo al proveedor y volver a instalarlo, y eso sin tener en cuenta que cambien puntos...eso despues del paston que cuenta... pienso que para la mayoria de gente no sea una buena solucion y creo que se ha de esperar a saber algo mas en el funcionamiento de la ps2 aunque estoy gratamente sorprendido de los comentarios de alguno de vosotros sobre el funcionamiento de la ps2, ojala os puediera ayudar...

Bueno, para continuar este hilo q estaba interesante os pego algo q he leido en el foro del messiah para ver q opinais...

Originally posted by Channeltech


NEO 4 is 90% built around Datel information, and we know exactly how and what they use to do it. This is why they are asking has anyone successfully got multiregion working on the new 'R' series consoles with the Datel Region-X, and if they have to contact them.

They then use te Datel information to build their patch information.

Theres nothing 'dodgy' or underhand in this, Datel for sure wouldnt think twice of producing a marketable product on something if they had the chance.. take the first DVD chips, along comes Datel and makes a bloody Region-disk.. bloody do-gooders !

But just for the curious and to answer the questions..
YES, NEO 4 is very much Datel 'hack' based and wouldnt exist if Datel didnt exist.

Despues de haber leido el hilo, estoy de acuerdo con casi todo lo dicho por USB.

Solo hay una cosa que creo que se ha escapado y a sido un detalle que puede parecer sin importancia, pero puede ser realmente importante. A la bios montan 9 o mas cables, por que 9 o 10 cables si el bus de datos son ocho, que hace esos hilos. Yo creo intuir que ese noveno hilo no es más que la habilitación o desabilitacion de la bios y el otro posiblemente toma la señal de reloj.

Si planteamos el funcionamiento de la bios de tal forma que la cpu le pide que le mande las cadenas de comprobación de los cds son originales, la bios mandara la informacón de sus registros la cual sera comparada con lo leido en el cd.

Si en vez de eso se desavilita la bios cuando se pide a esta la informacion para verificar los cds, y se inyecta lo que hay en el modbios la consola arrancara los cds. Aqui me surgen dudas, cuantos tipos de medios puede identificar la consola como correctos? que es lo que se inyecta? y mas...

La bios en si no realiza operaciones, pero puede aportar informacion para la realizacion de las mismas.

Mi opinion es que el messiah, el micro que utiliza esta muy sobre dimensionado, más que nada pora evitar copias. Si realmente los chips que se han de utilizar para PS2 han de ser de parcheo de la información de bios, micros más pequeños pueden ser usados como el nuevo clon de origa. lo que no entiendo es como aun no han aparecido clones de messiah, ya que tal vez nosotros con nuestros cortos recursos no tenemos osciloscopios con captura de buses, con los que espiar la comunicación mod - placa, y generar de esa forma otros mod.

Aun con todo creo que lo definitivo vendra por otro lado, en vez de parchear la bios, parchear la información que lee del cd y que posiblemente sera cargada por un bus serie.