Eremus escribió:Entiendo que el truco relativo a esto del que hablas es añadir una pagina de 16k y copiar alli la rom para que poke8 pueda usarla sin alterar la rom real. A expensas, eso si, de usar 16k de ram ¿Lo he entendido bien?
Tu tranqui, es tu pequeñin, tu adáptalo como mejor te venga.
Lo del array del contended, muy buena idea.
Exacto, para eso está el array de 4 punteros de lectura (gb_real_read_ptr_ram) y el array de 4 punteros de escritura (gb_real_write_ptr_ram), no hace falta, copiar ROMS ni nada. El de lectura, jamás va a ver el puntero de la ramFast, sólo el puntero de la rom que apunta rom en uso con su banco de rom. Y el de escritura sólo va a ver el puntero que apunta a
ramFast (cuando sea 0), pero le da igual, porque nadie la puede leer. El resto de 8 bancos de ram (ram0... ram7) sólo se acceden por cambio de banco. De está forma, la lectura sólo puede leer, en concreto sólo ROM cuando sea la página 0, mientras que la escritura sólo puede escribir, y jamás podrá hacerlo en ROM.
Siguiendo el pragma
use_optimice_writebyte se ve los puntos de anclaje de las actualizaciones de
gb_real_read_ptr_ram y
gb_real_write_ptr_ram. Lo de perder o no 16 KB (0x4000) de RAM para
ramFast, se puede arreglar con el truco
use_optimice_writebyte_min_sram de declarar ramFast de 1 o 2 bytes y aplicar:
Código: Seleccionar todo
#ifdef use_optimice_writebyte_min_sram
gb_real_write_ptr_ram[idRomRam][(idRomRam==0) ? 0 : (address & 0x3fff)] = value;
#else
gb_real_write_ptr_ram[idRomRam][(address & 0x3fff)] = value;
#endif
También se puede declarar un ramFast de 256 bytes y obligar a usar un indireccionamiento de 8 bits (256 posiciones), de forma que por over, al escribir en banco 0, ya nos ahorramos también los 16 KB. La forma inmediata es perder 16 KB, ya que no tiene que chequear nada. Ese bloque de 16 KB no interesa para nada, porque jamás se va a leer de él, es sólo para optimizar la forma de acceso por indireccionamiento, sin falta de chequear si es página 0 ni nada a la hora de escribir.
Las optimizaciones con
inline tienen el mayor éxito cuando son fácilmente reemplazables por una macro. Si el código a sustituir puede reutilizar los registros y la caché de la CPU, conseguimos premio, dado que nos ahorramos el apilar los registros al llamar a la rutina. Si la rutina es compleja, y usa muchos registros de CPU, aunque dentro hagamos
gotos a otras rutinas, no se consigue
premio. De ahí que cuanto más simple y menos lógica tenga la rutina, es decir, se le de todo más masticado, más posibilidades de éxito.
Felicitaciones por la Beta4. A celebrarlo.