Lo de ensamblador generico es porque no programo 6502, sino microcontroladores PIC, entonces me acostumbre a pensar en generico ya que todos los procesadores de 8 bits tienen mas o menos las mismas instrucciones basicas. Por ejemplo las comparaciones las pienso como si fueran IF, teniendo en cuenta que en asm todo se reduce a comparar igualdad, mayor o menor, o cero, entonces pienso la comparacion que tengo que hacer y luego veo como implementarlo en ese procesador. Se podria decir que lo compilo mentalmente, aunque no me sale de memoria el reemplazo de cada comparacion, siempre tengo que consultar el manual o copiar alguna otra similar que haya hecho antes, por eso aunque con este metodo puedo programar en lo que sea, me lleva mas tiempo hacer un programa. Sin embargo, lo bueno es que la documentacion queda muy bien porque lo que documento es lo que quise hacer en mas alto nivel, no el resultado en asm, es decir que suelo documentar cada bloque de 2 o 3 instrucciones. Pero cada cual tendra su metodo para programar, yo empece con 6502 en los 80s, y a principios de los 90s empece a programar PICs en asm, cosa que sigo haciendo, hace poco porte mi sintetizador de voz por soft para C64 a ordenadores con Z80 gracias a pensar en bloques logicos en lugar de en instrucciones, asi cada bloque seguia teniendo el mismo comentario en 6502 que en Z80, pero con distintas instrucciones y registros usados.
Un ejemplo de esto lo puse en el codigo que aparece en este mensaje:  http://retroinvaders.com/commodoremania/foro/index.php/topic,1080.msg12921.html#msg12921
En los comentarios se puede ver que comento todo, no dejo bloques muy largos sin comentar, pero que tampoco me pongo a detallar tanto, porque a veces el detalle aunque explica la razon de cada linea, oscurece lo que se pretende hacer. Hay veces en que se necesario el detalle linea por linea, por ejemplo en una rutina donde se hacen cosas con tiempos muy criticos y es necesario entender los tiempos de ejecucion, y otras donde basta con explicar de forma general lo que hace ese bloque, por ejemplo "copia tal bloque de memoria a tal direccion", "borra la pantalla", "inicializa y borra la pantalla de alta resolucion", etc.
En ese codigo de ejemplo use codigo automodificable para simplificar las cosas y ahorrar tiempo y memoria, como tenia muchos bucles donde se repetia mas o menos lo mismo y queria que tuviera un tiempo de ejecucion lo mas parejo posible, cargaba los valores directamente en el codigo, por ejemplo el numero de repeticiones de un bucle. A veces tambien "pokeaba" desde el codigo una instruccion de desplazamiento a la derecha o a la izquierda segun lo que necesitaba en ese momento, antes de ejecutar ese codigo modificado, y asi evitaba comparaciones y saltos que me hacian perder ciclos valiosos. Por supuesto que si no se hace bien puede ser desastroso, pero es una herramienta a tener en cuenta.

Hace mucho que solo las pruebo con fuente, segun wikipedia, las pilas duraban 4 o 5 horas, no se si alguna vez llegue a medir eso.

No me acuerdo ahora, jugue dos veces pero no es un juego que me atrape asi que no lo volvi a probar, hace mas de 10 años que lo probe, ahora no se si es que atacaban por turnos, es decir que uno atacaba y el otro defendia, o si colaboraban.
Con "Argh" te referias a Argentina? Yo conocia la consola desde el 91 porque era futuro amiguero (tuve la Amiga en el 92) y vi la Lynx en las pubicidades de las revistas de Amiga que habia empezado a comprar. La Lynx I es de 1989 y la II es de 1991, pero era un proyecto anterior a eso, era la consola que diseño Epyx y despues compro Atari.
Me olvidaba, yo nunca vi por aca esa consola, pero seguramente alguna habra llegado, en los 90s entraba de todo, si habia Laserdisc y Video Toaster, seguro habia Lynx tambien. Pero viviendo en la patagonia nunca vi nada de eso en persona. Las Lynx que tengo las compre todas en ebay como en 2002 o 2003, cuando no habia problemas con la importacion, el unico problema era tener dolares y que no estuvieran en el corralito. 

Yo lo probe con dos jugadores, los dos preparan el castillo cada uno en su consola, y despues empieza la batalla, no se si se puede jugar con mas de 2, el cable soporta hasta 4, pero para eso hay que comprar varios cables. El cable usa un miniplug y se conecta al estilo del serie de Commodore, encadenando las consolas, cada cable trae una salida para seguir conectando otros, no deberia ser dificil de armar. Recien encontre las dos copias de Rampart y solo una funciona, una lastima porque podia probar el juego en red y hacer un video, ya que tengo 3 Lynx.

Es una solucion posible, pero lo ideal es hacer una rutina donde se le pase como parametros que sprite se quiere mover, y un byte conteniendo la distancia a mover, expresada como un numero con signo, lo que permitiria con la misma rutina mover un sprite en la coordenada X un numero de puntos arbitrario entre -128 y 127. Despues se podria implementar de forma separada una rutina que haga el chequeo de limites para corregir las coordenadas si el numero dio negativo o excedio los 344 puntos que me parece que es el maximo permitido por el VIC.
Pero el codigo no es mucho mas complejo que lo que ya se esta haciendo, por ejemplo si el sprite esta en la coordenada 250 y queremos avanzar 10 puntos a la derecha, se sumaria 250+10, esto daria como resultado 260, que excede el valor 255, representado en binario 260 = 100000100, que es un valor de 9 bits, el bit 8 (el noveno) queda en carry, los otros 8 bits quedan como resultado, que en decimal seria 00000100 = 4. El bit 8, que queda en carry despues de la suma, vale 256 (2^8), por lo que el resultado de la suma es justamente 256 + 4 = 260. Ese valor que queda en carry debemos colocarlo en el bit mas significativo de la coordenada X de ese sprite para que no se pierda, y el resultado (el valor 4) directamente en el registro de coordenada X del sprite.
En definitiva, el sprite antes tenia en X el valor 250, representado como 250 en la coordenada X y 0 en el MSB de la coordenada X, y luego de sumarle 10, pasaria a tener el valor 4 en X, y 1 en el MSB de la coordenada X. No es una cosa rara, simplemente es un numero de 9 bits, y se coloca el bit 8 de cada sprite en un unico registro, pero siempre tenemos que tomarlo como un numero de 9 bits al que se le puede sumar o restar cualquier numero. Hay que tener en cuenta que la suma de dos numeros de 8 bits puede dar como maximo un resultado de 9 bits, 255+255 = 510 = 1 11111110 en binario, esto es, carry = 1, y resultado igual a 11111110 = 254. No es mas que un numero de 9 (o 16 bits si se quiere redondear a bytes enteros) dividido en dos partes, pero el bit 8 siempre vale 256, en el ejemplo, 256+254 = 510.
Para restar coordenadas ya es un poco mas complejo, pero el codigo no es mucho mas largo, solo hay que pensarlo un poco mas.

Todo esto esta muy bien como experimento, pero en la vida real uno no siempre avanza un sprite 1 punto a la vez, los juegos se hacen sincronizados con los 50hz de la pantalla, no se dibuja cada paso intermedio sino que cuando se va a mostrar la pantalla se dibuja todo donde debe aparecer. Por lo tanto las coordenadas de los sprites se almacenan en "variables" propias, no en los registros del VIC, y logicamente las coordenadas X usan 9 bits (dos bytes por cada sprite, o un byte por sprite mas otro byte para los MSB de los 8 sprites, tal como usa el VIC). Si tenemos un Pacman y el sprite tiene que salir por un lado y entrar por el otro, o si tenemos un juego donde el personaje entra en una puerta y sale en otro lado de la pantalla, cruzando la barrera de los 255 puntos, no podemos hacer un bucle para avanzar de una coordenada a otra solo para no complicarse la vida con coordenadas de 9 bits, ya que no sobra tiempo de proceso para eso.

En este mismo hilo, por el final de la primera pagina, se hablo de ese tema de los estilos para escribir en asm.

No pude encontrar un ejemplo de XOR en los punteros del raton, no recuerdo ahora en que sistema lo habia visto pero al parecer no era Windows 3.x ni MacOS, sin embargo el efecto era mas comun de lo que recordaba, se usaba para invertir los iconos seleccionados, cuando los iconos solian ser en blanco y negro (como en GEOS, o GEM Desktop del Atari ST), o para invertir una opcion de menu seleccionada. Lo que ganaban con eso era no tener que almacenar dos imagenes en memoria, y un poco de velocidad al evitar la transferencia de una imagen a la pantalla, ya que aplicaban XOR directamente en la VRAM.