Petición: ¡Queremos cargadores BASIC!

[zup]

Llevo una temporada "sabática" obligada (gracias a mi hijo) que me ha alejado un poco de la escena. Estos días estoy intentando ponerme un poco al día, y me preocupa un poco la tendencia que de poner cargadores c/m a los juegos de nueva hornada.

Entiendo que la gente que hace juegos le gusta ver un producto completo, y a mí también (he de confesar que me ha encantado el cargador con reloj de L'Abbaye des Morts) pero esto no está exento de desventajas. Por eso quería pedir a los desarrolladores que ofrezcan, además de la versión "guay" una versión con cargador normal en BASIC. Las ventajas:

- Carga en el divide sin problemas (estoy seguro de que Glauzone y Glaufight no van a funcionar en el divide, y L'Abbaye des Morts casi seguro que tampoco).
- Facilita convertirlos a disquetes para el +3.
- Los casualones podríamos usar POKEs sin rompernos mucho la cabeza.
- En algunos casos, los juegos cargan más rápido.

Algunos casos que me he encontrado últimamente:
- Glaufight y Glauzone: Sinceramente, creo que el Speedlock sobra. Si espiáis la memoria, veréis que está llena de zonas sin usar, y (tendría que hacer la prueba) creo que cargando solo lo que se necesita desde BASIC tardarían menos tiempo en cargar (el cargador Speedlock carga TODA la RAM).
- Sami Troid: Al margen de cierto problema (estoy perdiendo habilidades) que me he encontrado, es un juego muy interesante ya que utiliza compresión zx7. Una posible sugerencia sería hacer un cargador BASIC que cargue los datos comprimidos, los descomprima y después vuelva a BASIC antes de saltar al inicio del juego. Más que nada para que me dejen poner POKEs.
- Ninjajar!: Por primera vez los mojones han usado un cargador en c/m (bastante estándar). El juego usa mucha memoria (¿lo véis? ¡podéis usar la página 7 sin problemas!), y me imagino que la elección de usar un cargador en c/m ha estado influenciada porque había poco sitio para el BASIC (el juego empieza en 24200). Sin embargo, es posible hacer un cargador BASIC que quepa ahí
- Saucer: Caso raro. El legado que nos dejo Joffa (lo dejó como snapshot), ha sido "víctima" de las pruebas de un usuario de WOS y le ha puesto cargador ¡Alkatraz! En su defensa, decir que era una prueba de concepto de su rutina de grabación Alkatraz, pero no lo aprovecha (lo interesante de Alkatraz era su forma rara de cargar la pantalla). Años después, mirando lo que hace realmente, Alkatraz me gusta cada vez menos.
- L'Abbaye des morts: Este me ha sorprendido muy gratamente. Es un sistema muy cuidado, con el reloj que marca el tiempo que te falta por cargar y la compresión que usa para cargar menos datos. Como usuario, da gusto ver que hay gente que cuida tanto las cosas, como cracker... pues bueno, como cracker todavía me estoy dando de gorrazos contra él. Debido a todas las operaciones raras que hace, tengo detalles sueltos pero no la visión completa. Si me hincha mucho las narices aplicaré un poco de fuerza bruta, pero no es algo que me guste especialmente.

En fin, posiblemente me esté quejando de vicio, pero necesitaba compartir un poco mis pensamientos con vosotros.

[antoniovillena]

Pues yo recomiendo que se lean mi tutorial:

viewtopic.php?f=6&t=3948

Y que decidan ellos mismos.

Estoy de acuerdo en lo de que si van a hacer una versión ultracarga que pongan una alternativa en carga estándar, más que nada para la gente que usa DivIDE y para facilitarle la vida al que quiera pasarlo a disco. Pero no necesariamente un cargador BASIC es mejor que uno C/M, cada uno tiene sus ventajas y sus inconvenientes. Lo importante, creo, es que esté disponible el código fuente del juego, o al menos el del cargador.

Ninjajar en un principio tenía cargador BASIC pero andaban muy justos de memoria y no cabía todo. Dio la casualidad que saqué mi tutorial por aquella época y na_th_an se lo leyó y pasó el cargador a ensamblador.

[zup]

La petición era tener una versión "desprotegida" cada vez que haya una protegida por ahí.

El cargador BASIC es más adecuado si vas a meterlo en un divide o si quieres permitir que te POKEen. En su día, si querías evitar que manipularan el código o copiaran el juego, pues un cargador personalizado era mejor opción. Y ya ni hablamos de cosas como el cargador de Joe Blade 2... que te mantenía entretenido mientras jugabas.

El tema es que a día de hoy, salvo que quieras hacer una demo técnica, no hay demasiada justificación. Con un emulador moderno, no hay manera de evitar que te miren en el código todo lo que quieran (por ejemplo, crackear ahora un Alkatraz o un Speedlock es más fácil que crackear un search loader), así que ponerle un cargador raro no protege nada. Por otra parte, muchos autores ponen el código fuente disponible para todo el mundo... ¿entonces para qué proteger el juego?

El caso de Ninjajar es bastante extremo. Es el primer juego "indie" que veo que chupe tanta memoria, y de los juegos comerciales que he visto recientemente solo el Operation Wolf lo supera. Aunque es posible hacer un cargador casi exclusivamente en BASIC (tengo uno), usar el c/m era la mejor opción para compactar el cargador. En esos casos, una opción sería usar un cargador en c/m, retornar al BASIC y después saltar al código (para los que necesitamos POKEs).

[capzo]

A mi tambien me gusta la idea de poder acceder al cargador, pero confieso que las cargas exóticas tambien me van. Supongo que una versión con dos "caras" de la cinta, una con cargador custom y otra con standard en el mismo tzx seria lo suyo.

[zup]

Pensando un poco en la falta de espacio del NinjaJar!, acabo de hacer un miniexperimento que he llamado (por algún extraño motivo) el PringleLoader y que ocupa solo 93 bytes.

El BASIC me quedaría así:

Código: Seleccionar todo

10 PAPER NOT PI:CLS:RUN USR VAL "23825"
20 REM (62 bytes de relleno)

La sección en c/m sería la siguiente:

Código: Seleccionar todo

org 23781
newstack:
dw 16384
dw 6912
dw $1101

dw 49152
dw 14002
dw $1301

dw 49152
dw 16364
dw $1401

dw 49152
dw 16365
dw $1601

dw 49152
dw 16093
dw $1701

dw 49152
dw 16361
dw $1001

dw 24200
dw 36358
dw $1040

dw 24200   

inicio:      ;23825
di
ld sp, newstack
bucle:
pop hl
pop de
call 2036
pop af
ld bc,32765
out (c),a
jr nz,bucle
ret

Esto vendría a sustituir al cargador BASIC del Ninjajar! (que ocupa 157 bytes y ya es pequeño de por sí). No es que haya mucha ganancia, pero estaba preguntándome cómo podría hacerlo de pequeño. Se me ocurre alguna forma de arañar uno o dos bytes más, pero no creo que pueda hacerlo mucho más pequeño.

Hay dos o tres detallitos importantes con respecto a la línea 10. El org del código máquina está justo detrás del REM de la línea 20, siempre y cuando la línea 10 sea exactamente como está escrita. Si se ponen o se quitan cosas, habría que buscar ese REM y cambiar el org. Si se cambia el org, también cambiará la dirección de la etiqueta inicio, así que habrá que cambiar el USR para que coincida.

Por último, mientras el juego carga, el stack está en medio del BASIC. La consecuencia es que, mientras carga, la línea 10 se verá machacada. No importa demasiado ya que no pensamos volver al BASIC, y además la longitud de la línea 10 es suficiente para que no baje demasiado y machaque cosas como el área de variables. Incluso creo que si la línea 10 solo tuviera un RUN USR, tendría suficiente espacio para que el stack nunca llegara por debajo de 23755 (pero no tengo ganas de probarlo).

En cuanto al c/m, no hay mucho que destacar. La cosa va así:
1.- Ponemos SP mirando pa Cuenca (donde Cuenca es una región ocupada por los datos de los bloques a cargar) y ponemos el carry a 1.
2.- Extraemos el inicio y la longitud con POPs y llamamos a la rutina de carga de la ROM.
3.- Extraemos AF de la pila. Usamos A para meter la siguiente página a cargar (la primera vez, como cargamos la pantalla, no hace falta meter ninguna página especial).
4.- Truco: El bit 4 del registro de flags es el zero. Si no está activado (lo ponemos a mano tras cargar la última parte), volvemos al paso 2.
5.- Usamos un ret para saltar al código del juego. Tampoco ahorra espacio ya que 2 bytes de la pila + 1 byte de ret = 3 bytes de un jp 24200, pero queda chulo.

EDITO: Pifia en capacidad lectora. En otro hilo, antoniovillena decía que si llamabas a 2036 en vez de a 1366, te ahorrabas poner ld a,255 y el SCF. Mi pifia es que cuando lo probé seguía usando POP IX (cuando debía usar POP HL) y no cargaba para nada.

He sustituído call 1366 por call 2036 y he ahorrado otros 4 bytes.

[na_th_an]

Buenas. Me han avisado de que estábais hablando de Ninjajar! y su cargador.

El tema del Ninjajar es peliagudo. El problema no es que no cupiese el cargador BASIC, sino que el ISR del BASIC corrompe la página 7 en los +2A/+3. Al terminar de cargar e ir a ejecutar el juego, los datos de la página 7 han sido modificados (¿por el editor BASIC?) y cierta parte del script del último castillo no funciona y el juego no se puede completar. Esta fue la razón de usar el cargador en c/m de Antonio, el cual podía ejecutarse con las interrupciones deshabilitadas, con lo que toda la RAM estaba a nuestra disposición y no ocurren estas cosas.

Imaginaos, el día antes del lanzamiento, cuando el problema dio la cara. Lo que nos costó dar con la tecla de qué estaba fallando. Para volverse locos. Menos mal que nos dio por probarlo en el +2A (gracias, Davidian).

[zup]

defc timeout=$e600 ; (1) current disk motor timeout

Pues sí. He mirado mi propio cargador BASIC, y la única diferencia en toda la página 7 es esta variable.

Cada interrupción que pasa, este valor se decrementa y cuando llega a cero el motor de la disquetera se para. Me pregunto si habrá alguna forma de evitarlo...

En mi cargador de disco, cargo todas las páginas (excepto la 7) normalmente, luego cargo el código del juego y meto la página 7 comprimida con zx7 en la memoria de pantalla y vuelvo a BASIC. Después, hay un USR que pagina la RAM7, la descomprime, pagina RAM0 y salta a 24200.

Corrompes la memoria de pantalla, pero es la única forma que tengo de cargar los datos de la RAM7 en el +3e.

EDITO: Revisando lo último que he estado haciendo. Operation Wolf (Erbe) cae en la misma trampa (cambia ese byte en la página 7), así que estoy rehaciéndolo con la versión de velesoft. Por otra parte, tengo que revisar Typhoon (que también usa la página 7) y tener más cuidado con lo que hago.

Por otra parte, he mirado un poco el área de variables y ni indicándole al +3 que el motor está parado ni parándoselo a martillazos deja de tocar esa maldita variable... incluso lo hace un +2A que no tiene interfaz de disco ni motores que parar.

[wilco2009]

Desde el desconocimiento total y absoluto del problema. ¿Y algo tan sencillo como restaurar ese byte al final de la carga?

[zup]

Como cosa de 20 bytes en c/m. Pero no es tan importante como el hecho de que ese byte siempre se altera en los +2A y +3 (tengas o no disquetera, e independientemente del estado del motor de la disquetera). Si estás cargando desde cualquier disco (disquetera o disco del +3e), la cosa se complica mucho más.

Revisando los cargadores que he estado haciendo: Erbe metió la pata al menos en dos juegos (Typhoon y Operation Wolf). Supongo que habrá más, pero de momento esos dos tienen cargador en BASIC y la página 7 se ve alterada (comprobado con respecto a las versiones inglesas con Speedlock).

[wilco2009]

Sí, pero disculpa si estoy diciendo una chorrada, pero es que no lo entiendo.

Para los cargadores existentes está claro, pero si haces un programa desde 0 y el problema está en que el cargador BASIC hace que se modifique ese byte de la página 7, porqué no restaurar su valor desde el propio programa en CM cuando inicia su ejecución. Es decir, deshabilitas las interrupciones y ya tienes total libertad para escribir de nuevo ese byte.

[zup]

Sí, pero queda un poco chapucero. Sería el equivalente de tener una placa soldada profesionalmente y un cable agarrado con cinta aislante... funciona pero no queda elegante.

Este byte cambia solo en los +2A y +3 cuando tienes las interrupciones habilitadas (si cargas desde BASIC las tendrás habilitadas). La opción que han tomado los Mojon Twins ha sido cargar desde c/m con las interrupciones deshabilitadas y así evitarse tener que poner el parche antes de empezar el juego, que es más sencilla que meter a martillazos ese byte en su sitio.

Si cargas desde BASIC, tendrás que poner obligatoriamente ese byte antes de empezar el juego. Es básicamente lo que hago en mis cargadores de +3 cuando se usa la página 7... aunque meto a martillazos bloques bastante más gordos porque al cargar de disco se corrompen áreas más grandes (en realidad suelo restaurar o bien toda la página 7 o bien sólo de la dirección 6912 en adelante).

Lo importante del caso, insisto, es que si no tocas las interrupciones del +2A/+3 ese byte va a cambiar. No importa que estés cargando o no, va a cambiar. En el caso de los Mojon Twins el error se producía en la carga, ya que después utilizan su propio manejador de interrupciones; pero otra consecuencia importante es que si un juego usa el manejador de la ROM y almacena datos en la página 7 estos van a corromperse.