Último mensaje de la página anterior:
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.