Page boundary crossed

[Maniako]

Ando haciendo un jueguecillo usando el CBM prg Studio y de vez en cuando me aparece este error que hasta ahora me tenia frito. El programa funciona siempre sin problemas, pero al final me he decidido a buscar qué significa.

Leyendo por ahí http://www.6502.org/tutorials/6502opcodes.html#BMI, lo que he creído entender, es que si haces un salto por ejemplo:

10FE                      bmi salto1
......
1102  salto1           sta pokemon

Parece ser que un salto a otra página de la memoria, conlleva un ciclo más para su ejecución, con lo cual, pierdes tiempo de proceso. ¿Se consideran páginas separadas 1000-10FF de 1100-11FF?.

Moviendo subrutinas "encima" de la que me da este error, lo ha hecho desaparecer, lo cual me da a entender que si lo es.

10FE                      NOP
10FF                      NOP
1100                      BMI salto1
.......
1104                      STA pokemon

Desplazándolo de esta manera, el error desaparece. Supongo que es un ciclo que me ahorro.
Os dejo una "demo" del juego. Solo se mueve la nave, igual que la rutina que colgué en otro hilo, pero con mejoras. Así os echáis unas risas XD

[pastbytes]

Las paginas son 256 bytes, por eso el direccionamiento de pagina cero accede a las direcciones de memoria de 0 a 255. Si el byte mas significativo entre dos direcciones es diferente, las direcciones estan en paginas distintas.
En el manual del programador del C64, cuando detalla las instrucciones del 6510, donde dice cuantos ciclos consume se aclara lo de cruzar el limite de la pagina, que agrega un ciclo extra, supongo que tendra que ver con que al cruzar el limite tiene que sumar o restar tambien el byte mas significativo del contador de programa.

[Maniako]

Leer lo leía, pero comprenderlo sin ejemplos claros no. Entiendo que gasta un ciclo incrementando el hibyte para alcanzar su destino.
Así que es correcto y necesario si deseas optimizar el código.

Muchisimas gracias.

[josepzin]

¿Pero ese ciclo perdido en qué afectaba?

[Maniako]

¿Pero ese ciclo perdido en qué afectaba?

Uno solo?. En casi nada. Pero si ejecutas un bucle donde esa instrucción ("error") se ejecute muchas veces, pierdes tiempo de ciclo a la hora de ejecutarse y si encima este error lo recreas en muchas de tus rutinas dentro del mismo programa , pues más tiempo perdido que acumulas.

Ya que estoy aprendiendo, mejor hacerlo bien para cuando haga cosas que necesiten rapidez como hacer scroll a pantalla completa o demos/presentaciones.

No sé, creo que es lo mejor.

[Laddh]

Tampoco te obsesiones con eso Maniako, es un warning, no un error, cuando tengas un proyecto grande tendrás unos cuantos. Yo quite mas de cien en uno de mis proyectos y no era perceptible el ahorro de ciclos. No vale la pena el esfuerzo. Quizás solo si la rutina es muy repetitiva y cabe en una página.

[Maniako]

Mejor hacerlo bién de primeras 

Ando haciendo un jueguecillo y la mayor parte del programa está hecho a base de subrutinas, así, con mover los bloques o subrutinas me vale para arreglar ese "problema" y no tengo que reescribir todo el código.

[riq]

no se que ensamblador estas usando. yo uso el ca65 y tiene el ".align" que es para que pongas tu código alineado a lo que necesites. es útil para cuando un ciclo puede afectar una rutina.
http://cc65.github.io/doc/ca65.html#ss11.4

pero si abusas del ".align 256" entonces todos va a ocupar más memoria. es un tradeoff entre memoria y performance.
como sugerencia, no te preocupes de este ciclo de más ahora. y luego ve si tu juego necesita más performance.  si es así, probaría primero con: macros, unrolled loops, tablas (y más tablas)  que son los que te pueden dar un gran salto en la performance.
y cuando necesites hilar más fino, el ciclo extra que mencionaste más otros truquitos del 6502 ayudan. por ejemplo, estos:
https://wiki.nesdev.com/w/index.php/6502_assembly_optimisations

[Maniako]

Uso el CBMprgStudio 3.8.0.
La verdad es que no tengo ni idea de si dispone de esa herramienta en concreto ya que desconocia ese problema hasta hace poco.
He de suponer que si. Lo miraré este fin de semana.

Las tablas son mi biblia. Ahorran muchisimo tiempo de comprobaciones cuando eres capaz de hacer que las condiciones de uso del programa realicen los ajustes de manera natural.
Los unloops ya ví el tiempo que tomaban y aunque ocupe mucho más espacio una rutina de mover bloques, la rapidez compensa.
 
Aunque esté empezando (reaprendiendo) con el ensamblador, creo que lo preferible es irse "liando" con esos trucos de ahorro en ciclos. El saber no ocupa lugar (aúnque consume de tiempo...  ).

Muchisimas grácias por esa web.

[riq]

Aunque esté empezando (reaprendiendo) con el ensamblador, creo que lo preferible es irse "liando" con esos trucos de ahorro en ciclos. El saber no ocupa lugar (aúnque consume de tiempo...  ).

si, desde ya. esta bueno aprender estos trucos.