Switch virtualizando Vita

[Drumpi]

Buenas a todos:

Según MVG, se ha conseguido virtualizar (o como él dice, traducir las llamadas de Vita en funciones de Switch) parte del funcionamiento de la Vita.

https://www.youtube.com/watch?v=tLAhhUKsWck

No significa que se haya virtualizado todo, solo una parte muy básica (dado que la CPU ARM8 64bits de la Switch tiene un modo compatible, "legacy", con el ARM7 32bits de la Vita), y que aún están trabajando en ello. Según parece, ahora están volcados en traducir los "shaders", que son radicalmente distintos y les va a llevar tiempo. No conozco los intríngulis de ambas máquinas, así que no sé hasta dónde pueden llegar.

Cuando acaben, alguien les tiene que proporner que sigan con la GP2X, que será un ARM más antiguo, pero la negrita se lo merece :lovegp2x: :awesome:

[swapd0]

Ayer vi el video, XD.

Es curioso pensar que por ejemplo si otras consolas que llevan un 68000 a la hora de tocar el hardware lo hicieran llamando a una librería casi podrías cambiarla y así "portar" juegos de Amiga, Atari ST, Megadrive, NeoGeo, x68000, Jaguar, etc entre si. :P

[Drumpi]

Bueno, si puedes sustituir las direcciones de memoria que apuntan al HW por direcciones de atributos de una clase, lo mismo sí que podrías hacerlo... creo. Al fin y al cabo es lo que hacen los emuladores.
De hecho, sería interesante un proyecto que conectase el 68000 a un CI que redirigiera los datos a los puertos del HW según se configure el sistema en modo x68000 o Jaguar. Es decir, que si uno tiene el sintetizador Yamaha STxxx a parti de la dirección H005000 y el otro de la H00F000, pues que modifique la ruta. Claro que el proyecto necesitaría incorporar todo el HW de todas las máquinas, y dudo que haya muchos elementos comunes o compatibles entre sí :P

Y quien dice 68K, dice Z80 o el otro procesador que nunca me acuerdo del número, el 6xxx :D

[swapd0]

El problema en algunos casos es que no se usa hardware "off shelf", asi que tendrías que poner una fpga que hiciera esa parte.

-----Actualizado-----


Bueno, si puedes sustituir las direcciones de memoria que apuntan al HW por direcciones de atributos de una clase, lo mismo sí que podrías hacerlo... creo. Al fin y al cabo es lo que hacen los emuladores.
Mas o menos es lo que hizo este tío, parcheo el juego para que en vez de tocar los registros del x68000 los escribiera en una determinada dirección de memoria y después se hizo sus rutinas de sprite.

Lo que pasa es que en el caso de la switch/psp vita, son librerías dinámicas que carga el SO, en el caso del x68000 tienes que buscar tu a mano donde se toca eso y cambiarlo ya que no hay manera de saber donde se tocan los registros.


https://www.youtube.com/watch?v=DsyJF32BMHw

[masteries]

El problema en algunos casos es que no se usa hardware "off shelf", asi que tendrías que poner una fpga que hiciera esa parte.

-----Actualizado-----


Mas o menos es lo que hizo este tío, parcheo el juego para que en vez de tocar los registros del x68000 los escribiera en una determinada dirección de memoria y después se hizo sus rutinas de sprite.

Lo que pasa es que en el caso de la switch/psp vita, son librerías dinámicas que carga el SO, en el caso del x68000 tienes que buscar tu a mano donde se toca eso y cambiarlo ya que no hay manera de saber donde se tocan los registros.




El colega Anima in Corpore, por lo general Anima hace mucho más que eso, la versión Falcon es mucho más compleja... casi todo lo relacionado con el dibujado, el limpiado y las órdenes del blitter está trasladado al DSP de 32 MHz que montan los Atari Falcon.

Un pepinaco de ordenador, incluso se ha llegado a hacer que sea este DSP quien realice el trabajo de T&L y texturizado para el motor de Half-Life, Quake 2 y Quake 3 (DML)... en estos últimos casos no logras superar 15 FPS, pero mover los gráficos de Half-Life a 320x240 a color de 16 bits, a una tasa de entre 10 y 15 FPS en un ordenador de 1992, ampliado a su máximo de fábrica 14 MB de RAM, dice mucho de lo avanzado a su tiempo que es el Falcon.

Otras ampliaciones, que incluso salieron en vida comercial del Falcon, te permiten ponerle hasta 128 MB, pero ya toca abrir y hacer alguna ñapa.

[Drumpi]

El problema en algunos casos es que no se usa hardware "off shelf", asi que tendrías que poner una fpga que hiciera esa parte.

-----Actualizado-----


Mas o menos es lo que hizo este tío, parcheo el juego para que en vez de tocar los registros del x68000 los escribiera en una determinada dirección de memoria y después se hizo sus rutinas de sprite.

Lo que pasa es que en el caso de la switch/psp vita, son librerías dinámicas que carga el SO, en el caso del x68000 tienes que buscar tu a mano donde se toca eso y cambiarlo ya que no hay manera de saber donde se tocan los registros.


https://www.youtube.com/watch?v=DsyJF32BMHw

Pero con la dirección del bus sabes hacia dónde va el dato, porque sabes el mapa de memoria de cada máquina. Si hay dos máquinas con misma CPU, y mismo HW pero mapeado de forma distinta, sólo tienes que redirigir las llamadas. Si un HW es distinto, por ejemplo, que uno tenga un DSP de Motorola y otro de Texas Instruments, pues para que funcionen tendrás que tener ambos chips en la placa y dirigir los datos al que le corresponda, según la máquina en ejecución... o bien dirigirlo a la zona de la RAM donde se simula dicho DSP, o que el SO le envíe el dato a la librería del sistema que controla el DSP instalado.

Entiendo que será mucho más difícil que lo que planteo, pero un 68K sólo manda y recibe datos a unas direcciones, es responsabilidad del programa saber qué hay en esa dirección, y lo mismo que tu le mandas un buffer de una imagen a un DSP, yo en clase le he mandado una serie de unos y ceros a una matriz de leds. Es como hacer un parser, que puede ser SW o HW.