Hola, recuerdo que en varios foros en Inglés se comentó que un teórico oc al svp no aumentaría la velocidad del juego por la forma en la que trabaja el chip y por la própia programación de VR, que predetermina el número de fps de forma invariable, creo que
aqui se confirma.
"
The SVP code doesn't seem to be timing sensitive, so it can be emulated without
knowing timing of the instructions or even how fast the chip is clocked.
Overclocking doesn't have any effect, underclocking causes slowdowns. Running
10-12M instructions/sec (or possibly less) is sufficient."
"
SVP seems to have DMA latency issue similar to one in Sega CD, as the code
always sets DMA source address value larger by 2, then intended for copy.
This is even true for DMAs from ROM, as it's probably hooked through SVP's
memory controller."
"
The entry point for the code seems to be at address 0x800 (word 0x400) in ROM,
but it is not clear where the address is fetched from when the system powers
up. The memory test code also sets up "ld PC, .." opcodes at 0x7f4, 0x7f8 and
0x7fc, which jump to some routines, possibly interrupt handlers. This means
that mentioned addresses might be built-in interrupt vectors."
En su día tambien me lo planteé, y pese a no tener ni idéa de programación ni conocimiento alguno de hard, llegué a una conclusión que cierta o no me permitió aparcar la obsesión por el tema: para que VR (más los juegos que se iban crear inicialmente para el SVP, de haber sido programados) corriera a una velocidad mayor, bastaría con volver a programarlo con la orden de utilizar sólo 8 o 5 colores en pantalla y un menor número de polígonos, de nada valdría hacer oc porque el código del juego impone de forma inflexible que se muestre a 10 fps, a diferencia de los juegos de PC por poner un ejemplo fácil, donde si se contempla que los juegos tengan mayor o menor complejidad y velocidad en función de la capacidad del ordenador.
Si se pretende una mayor carga poligonal en VR, habría que sacrificar colores y velocidad, aunque en éste caso si no me equivoco sería justo al revés: al realizar el juego con una mayor cantidad de polígonos que la usada por programa original y dar la orden de ejecución, el mismo svp se encargaría de recortar la velocidad, al ser incapaz de manejar con soltura ese número de poligonos.
En todo caso sería apasionante ver juegos homebrew programados para SVP o SFX
Saludos