En estas últimas semanas me dediqué a desensamblar y documentar el codigo de la expansión de comandos Sprite BASIC para C64, algo que quería hacer hace varios años, por curiosidad, para saber como funciona una expansión de comandos y si se puede, agregar más comandos.
]spritebasic_source.zip[/file]

Estuve mirando un poco el codigo (todavia no lo probe el sprite basic), que complicacion que el vic lo mapeen a otra area de la RAM, a mi me sacas el poke 1024 y no se que hacer en el basic! y por lo que veo a la vez te roba de los 16Kb del VIC para correr el programa en la misma zona! no queda espacio para los sprites y para acceder al VIC a la memoria de sprites hay que tocar el mapeado? y lo mismo para la memoria de color en D800? que lio!

El VIC lo mapea en C000-FFFF, el sprite basic usa C000-CBCA para guardar sus comandos.
Despues en CC00 vienen los 1000 bytes de la pantalla de texto del BASIC, seguido de los 8 punteros de los sprites
En E000-EFFF estan las definiciones de los sprites, y en F000-FFFF el juego de caracteres.
Los sprites y los caracteres estan en la RAM por debajo de la ROM del Kernal, pero desde el punto de vista el VIC no hay drama porque siempre ve RAM en esa zona.
Desde el punto de vista del spritebasic lo que hace es banquear la RAM al ejecutar un comando de definicion de caracteres o sprites, y volver a banquear la ROM al terminar el comando.
En esas ocasiones y al iniciar el sprite basic son las unicas en las que se usa el banqueo de RAM/ROM

Y el BASIC solo pierde 4K de espacio de variables.

La RAM de color en D800 no es problema porque el VIC siempre la ve en la direccion en la que esta la pantalla de texto, sin importar cual sea. (la RAM de color usa los 4 bits superiores del bus de datos de 12bits del VIC)

No puedo hacer una comparación entre el ACME y el DASM porque yo siempre he usado ACME, la documentación es bastante buena, viene dentro del zip. Lo que tiene de bueno es que hay version Linux (hay que compilarla)

El único problema que tuve fue con las etiquetas calculadas que use en el spritebasic (que serían las de tiempo de ejecución). No las pude usar como parametro de saltos condicionales porque las toma (correctamente) como variable de 16bits en lugar de como una etiqueta y calcular el offset.

Una ventaja que tiene, al menos no se si lo tendra el DASM, es que tenes comandos para entrar texto en formato ASCII, PETSCII o codigo de pantalla. Para poder 'pokear' el texto directamente a la pantalla de texto.

El VIC lo mapea en C000-FFFF, el sprite basic usa C000-CBCA para guardar sus comandos. Despues en CC00 vienen los 1000 bytes de la pantalla de texto del BASIC, seguido de los 8 punteros de los sprites En E000-EFFF estan las definiciones de los sprites, y en F000-FFFF el juego de caracteres. Los sprites y los caracteres estan en la RAM por debajo de la ROM del Kernal, pero desde el punto de vista el VIC no hay drama porque siempre ve RAM en esa zona. Desde el punto de vista del spritebasic lo que hace es banquear la RAM al ejecutar un comando de definicion de caracteres o sprites, y volver a banquear la ROM al terminar el comando. En esas ocasiones y al iniciar el sprite basic son las unicas en las que se usa el banqueo de RAM/ROM Y el BASIC solo pierde 4K de espacio de variables. La RAM de color en D800 no es problema porque el VIC siempre la ve en la direccion en la que esta la pantalla de texto, sin importar cual sea. (la RAM de color usa los 4 bits superiores del bus de datos de 12bits del VIC) 

the woz