Fermars escribió:elfoscuro escribió:Sobre el que no se pare:
http://microhobby.speccy.cz/mhf/136/MH136_07.jpg
Parece ser que era algo habitual en la época
Ahora, no te pares aquí. Investiga más, y mejora el sistema. Mhoogle es una gran herramienta de aprendizaje.
Un saludo.
Pues te va a parecer curioso, pero para parar el microdrive una vez que está en marcha y no deja de dar vueltas hago exactamente lo que dice en ese artículo, un reset y un CAT. Después un Break lo para siempre. El problema realmente no es ese, porque lo del microdrive puede pasar de forma aleatoria de vez en cuando por 1000 razones, pero en este caso sucede siempre, es decir, da la impresión que no puede volcar en memoria el contenido que previamente había grabado, incluso apagando y encendiendo.
Pasando página, lo que realmente me gustaría saber de los listados anteriores son varias cosas, ya a nivel de programación en BASIC. La verdad es que en listado del salvapantallas a mi entender y dado los ínfimos conocimientos que tengo, me las ingenié bastante bien, manual del Spectrum en mano, para usar el GOSUB y el RETURN, así como terminar el bucle con el valor de "q". No se si habrá otra forma de hacerlo más fácil, pero a mi me sorprendió que funcionara la idea.
Mírate este programa a ver si lo entiendes:
Código: Seleccionar todo
10 CLEAR 24999: DIM N$(5):DIM p(5)
20 LET N$(1)="flight":LET N$(2)="pssst":LET N$(3)="flag":LET N$(4)="jetpac":LET N$(5)="raiders"
20 LET p(1)=25856:LET p(1)=32768:LET p(1)=39680:LET p(1)=46592:LET p(1)=53504
30 FOR f=1 TO 5
40 PRINT "Pantalla ";f;": ";N$(f)
50 PAUSE 0
60 CLS
70 LOAD *"m";1;N$(f) CODE p(f),6912
80 NEXT f: REM bucle que carga las pantallas una a una según se pulse una tecla
90 RESTORE 100: FOR f=0 TO 11:READ a:POKE 25000+f,a:NEXT f
100 DATA 17,0,64,33,0,0,1,0,27,237,176,201: REM bucle que mete el código máquina
100 IF INKEY$<>"" THEN STOP: REM sale si se pulsa una tecla
110 FOR f=1 TO 5
120 LET b=INT(p(f)/256)
130 LET a=p(f)-256*b
140 POKE 25004,a
150 POKE 25005,b
160 RANDOMIZE USE 25000
170 PAUSE 100
180 NEXT f: REM bucle que muestra las pantallas una a una, con 2 segundos de retardo.
200 GO TO 100
Lo primero, te habías dejado el CLEAR, por lo que imagino que al cargar las pantallas estabas machacando algo de los mapas del microdrive y quizá por eso no se paraba el motor. A ver si poniendo el CLEAR se soluciona. SIEMPRE que trabajes con código máquina, o datos en memoria (PEEK y POKE), debes hacer el CLEAR para crear esa parte de memoria protegida dónde el sistema no mete nada. Te evitarás problemas.
Te he puesto instrucciones como DIM para que investigues. He quitado la rutina de GO SUB porque realmente no es necesaria, y te he puesto bucles, y lo que odian los profes de informática, salidas "a lo bruto" con el INKEY$. Pero, en Spectrum, se hacía así XD XD
Fermars escribió:
Por otro lado no tengo claro lo siguiente:
1. En la línea 100 ¿porqué el bucle FOR va de 0 a 11? Según eso, el POKE iría del 25000 al 25011 ¿por qué?. Entiendo que el valor "a" son los DATA de la línea 110, ¿es así?
Realmente da igual. El código máquina que te han puesto es totalmente reubicable, por lo que es lo mismo dónde se ubique. Podrías haber puesto el bucle 1 TO ..., pero habrías tenido que cambiar el RANDOMIZE USR a 25001 en lugar de 25000. Por cierto, RANDOMIZE no forma parte de la llamada a código máquina. Es la función USR la que lo hace. RANDOMIZE es un iniciador de números aletorios, y se podría haber usado LET z=USR 25000, PRINT USR 25000... en su lugar, es decir cualquier instrucción que use una función. Te lo explico, porque si ves otros listados, igual lo ves así en lugar de RAND. USR devuelve un número, que le puedes dar desde el código máquina. Si, por ejemplo, te creas tus propias rutinas de cálculo, podrías aprovechar ese número como resultado.
Fermars escribió:
2. ¿Cómo sabemos qué DATA son los que hacen falta para hacer lo que deseamos?
Lo marca el RESTORE. Esta instrucción pone el puntero de READ en la línea que quieras. Lo puedes usar para definir un UDG según un valor, por ejemplo. Teniendo varias líneas DATA, si haces un INPUT al usuario para su idioma por ejemplo, podrías definir los UDG "N" como Ñ, o dibujar la libra o el dolar, según el país, etc. Cada pais estaría en una DATA, y haciendo el restores a esa línea, podrías dibujar directamente el caracter que fuera, sin tener que hacer varios bloques FOR.
Aunque ahora releyendo, no se si te refieres a esto, o a porqué tenemos estos números y no otros... Si es eso, te diré que esos números son los necesarios para meter en memoria el miniprogramita en código máquina (assembler) que mueve las pantallas. Para hacer otras cosas, habrá otras DATA diferentes. Quizá esto, junto con mi respuesta siguiente, te aclare más cosas.
Fermars escribió:
3. ¿Por qué en la línea 300 usamos las direcciones del POKE 25004 y 25005? y lo que me deja ya fuera de juego totalmente, ¿por qué la ejecución del programa únicamente la hacemos en la dirección 25000 (línea 310)?
Si revisas el código máquina, verás el porqué. A grosso modo, lo que hace el programa es:
Código: Seleccionar todo
10 LET destino=16384: REM DATA 17,0,64 (64*256=16384)
20 LET inicio=30000: REM 33,0,0 --- ponemos 0,0 porque estos son los valores que cambiaremos siempre, da igual lo que valgan al principio
30 LET longitud=6912: REM 1,0,27 (27*256=6912)
40 FOR f=0 TO longitud-1: POKE destino+f, PEEK inicio+f:NEXT f: REM esto sería el LDIR --- 237,176
50 RETURN: REM esto sería el RET --- ,201
Lo que hacemos es cambiar el valor de inicio, que está en 25004 y 25005 por el que necesitemos según la pantalla. Destino y longitud siempre serán el mismo valor, la dirección de la pantalla y el tamaño, y no los tocamos. Pero, si lo que hicíeramos fuera de la pantalla a la dirección 30000, no tocaríamos 25004 y 25005, si no 25001 y 25002.
Mientras que el código máquina lo hace en un suspiro, el BASIC es lento de narices. Si cambias el RANDOMIZE USR 25000 por este código, podrás comprobar la diferencia. Es brutal.
Creo que te puse unos enlaces a unas páginas de MicroHobby dónde se veía todo esto en detalle. Revisa el hilo, porque creo que eran dos páginas que explicaban el tema bastante bien (antes de lo de comprimir pantallas me suena).
Un saludo.