Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - alakran

Páginas: 1 [2] 3 4 ... 8
16
Problemas Hardware y Software / Re:Ratón 1351
« en: Septiembre 04, 2015, 15:39:13 »
Para sacarte la duda, bajate el Art Studio con soporte de mouse de Amiga.

http://csdb.dk/release/?id=58683

Y probalo en el puerto 1.

Yo tuve un mouse de amiga y lo probé con ese programa. Funciona bien.

17
General / Re:Nuevos juegos publicados
« en: Septiembre 02, 2015, 17:14:38 »
¡Increíble! Año a año se pone cada vez mejor. Jugué al Awakening y lo pude terminar. Me encantó, y se me ocurre que está al 100%. Muy pulido, no creo que sea una versión preliminar que luego vayan a mejorar. Si alguien se traba y necesita ayuda, mande PM.
Y el Caren, llegué lo más lejos que pude, pero está lleno de bugs y quedé atrapado en una pantalla sin posibilidad de salir por donde había entrado. :-(
Me parece que llega hasta ahí. Además me doy cuenta de que por un error, no es necesario resolver los problemas en algunas partes para que el juego avance (clave para usar la computadora, y la tarjeta modificada).
Pero cuando lo terminen va a ser uno de los grandes juegos de la historia de la C64. No puedo creer los gráficos. ¡La sombra de Caren en el piso del laboratorio!

18
General / Re:1541 Ultimate II
« en: Agosto 21, 2015, 16:50:29 »
También podés escuchar archivos .mod con el Ultimate y el sonido sale por ahí.

19
Desarrollo / Re:Detectando PAL/PAL-N/NTSC/NTSC-Old
« en: Agosto 19, 2015, 02:23:21 »
Logré cargar los programas en el equipo Drean, metiéndolos en un d64.
Las dos versiones del vic_detect no funcionan.
Sí funciona el juego. Dice PAL-N.
(Este equipo tiene un problema por el cual no funciona el reset del Ultimate 1541)

20
Desarrollo / Re:Detectando PAL/PAL-N/NTSC/NTSC-Old
« en: Agosto 19, 2015, 02:13:23 »
Recién probé los programa en mis 3 equipos.
En PAL-B funciona todo.
En uno originalmente europeo, modificado a PAL-N, el vic_detect no funciona. No dice nada.
Sí funcionan la segunda versión del vic_detect, y el juego.
En un equipo Drean, no funciona nada, porque anda mal y no puedo cargar los programas.

21
Desarrollo / Re:Detectando PAL/PAL-N/NTSC/NTSC-Old
« en: Agosto 18, 2015, 19:14:52 »
O si Alakran tiene un D64C puede probar también él.

Si. Tengo uno que era europeo y fue modificado a PAL-N.
Y tengo uno Drean, que está bastante baqueteado y no le tengo confianza.
Hoy a la noche lo pruebo.

22
Desarrollo / Re:Detectando PAL/PAL-N/NTSC/NTSC-Old
« en: Agosto 18, 2015, 07:53:35 »
Probado en un Drean C64C... cuelgue total. No aparece ningún mensaje.

Noo. ¡Mea culpa! ¡Mea culpa!
Me siento un estafador. Esto lo tenemos que arreglar. ¡Qué te di!
Vas a tener que aceptar un resarcimiento.  :-[


23
General / Re:El Castillo del Dragón
« en: Agosto 10, 2015, 01:07:48 »
Según recuerdo, por lo comentado sobre el tema, se supone que.en cada partida el mapa es nuevo pero que al unir las dos cargas esto no estaba funcionando.

Creo que eso ocurría porque freezaban el programa. O sea, una copia exacta de la memoria, incluída la variable TI del reloj, que luego el programa usaba para generar el mapa aleatorio.

24
General / Re:El Castillo del Dragón
« en: Agosto 10, 2015, 00:59:20 »
Una última cosa, que acabo de caer en cuenta. A partir de la modificación que hice en code.prg (al cambiar su posición de $033c a $0800) ya no es necesario mover la "decrunch table" en el exomizer. Todo más sencillo. Así que quedaría así.

exomizer sfx basic,$4001,$7300 code.prg mil.prg charset.prg basic.prg,$4001 joystick.prg screen.prg screen_c.prg -n

25
General / Re:El Castillo del Dragón
« en: Agosto 09, 2015, 22:35:44 »
Acá repaso línea por línea qué hace el cargador:

10 rem el castillo del dragon
20 rem parte 1 - cargador
30 :
100 b=14336:c=55296
105 :
110 poke56333,127:poke179,192
115 poke1,peek(1)and251
120 fori=0to2047:pokeb+i,peek(c+i):next
125 poke1,peek(1)or4
130 poke56333,129

Ahí genera una copia idéntica del juego de caracteres que viene en el equipo, ya que luego algunos de ellos van a ser redefinidos. Pero al ser muy pocos, es más cómodo primero copiar todos y luego cambiar los que sean necesarios.
Los caracteres nuevos ocupan la zona de memoria desde 14336 (B) hasta 16386 y son tomados de la zona 55296 (C).

135 :
140 fori=512to719:pokeb+i,0:next


Acá llena de ceros la zona de memoria desde 14848 hasta 15055. O sea, borra algunos caracteres del nuevo juego.

145 reada:ifa<0then165
150 fori=0to7:readx
155 pokeb+a*8+i,x:next:goto145


Acá sobreescribe algunos de los caracteres de la nueva definción, para que no sean idénticos a los que viene por defecto; a saber, el escudero, la puerta, etc.
Fíjense que antes había pokeado la zona de B, desde 14336 hasta 16386, o sea, el set de caracteres completo. Y ahora toma 2 valores de los datas: El primero (A) le indica la distancia de B, o sea el caracter específico que quiere redefinir. Y luego toma los 8 valores de X que le dan la forma al nuevo caracter. Cuando encuentra un valor menor a 0 (el último data de la sección "JUEGO CARACTERES") pasa a la siguiente línea.

160 :
165 fori=828to1023:reada:pokei,a:next


Acá toma la segunda sección de los datas, que lleva por nombre "CODIGO MAQUINA"
y la ubica desde la posición de memoria 828 hasta 1023, o sea desde $033C a $03ff

170 fori=49152to49270:reada:pokei,a:next

Acá toma la tercer sección de datas, denominada "JOYSTICK"
y la ubica desde la posición 49152 hasta 49270, o sea desde $c000 a $c076

175 fori=50176to51175:reada:pokei,a:next

Acá toma la cuarta sección de datas, denominada "PANTALLA"
y la ubica desde la posición 50176 hasta 51175, o sea desde $C400 a $c7e7

180 fori=51200to52199:reada:pokei,a:next

Acá toma la quinta sección de datas, denominada "PANTALLA COLOR"
y la ubica desde la posición 51200 hasta 52199, o sea desde $c800 a $cbe7

Bien. Hasta aquí lo único que hizo el programa es llenar espacios de memoria, que pueden ser volcados directamente al disco como archivos independientes.
Eso hice. Y le puse los siguientes nombres:
CHARSET, CODE, JOYSTICK, SCREEN y SCREEN C

Continuemos...

185 poke53280,0:poke53281,0:printchr$(14)chr$(8 )

Acá cambia el color de fondo a negro y cambia de mayúscula a minúscula. La combinación "printchr$(14)chr$(8 )" hace además imposible volver a cambiar de mayúscula a minúsculas.
Como indiqué en otro mensaje, esta parte del código, si vamos a prescindir del cargador, es necesario agregarla al segundo listado.

186 print"“e    Un momento, por favor"
187 print"qpoke44,64:poke64*256,0:new"
188 print"qqfori=0to118:poke4096+i,peek(49152+i):next"
189 print"qqload"chr$(34)"dragon.prg"chr$(34)",8s";
190 poke198,3:poke631,13:poke632,13:poke633,131:end
191 :


Acá es interesante lo que hace. Imprime en pantalla "Un momento por favor" y luego en el mismo color que el fondo, para evitar que lo veamos, un par de instrucciones que luego va a ejecutar con la línea 190.

La línea 187 hace un POKE44,64 . O sea, se ubica en la posición de memoria $4000
Como había indicado en otro mensaje, la intención del programa es cargar un segundo listado, el juego propiamente dicho, en la posición de memoria $4000
Luego hace un POKE64*256,0 , o sea pone un cero en la posición de memoria $4000
Como todos (?) sabemos, si tenemos un listado de basic a partir de la posición de memoria $0801, para poder darle RUN, la posición de memoria $0800 tiene que ser un cero. Si no, no funciona. Lo mismo con cualquier otra posición de memoria. El valor anterior a donde inicia el programa tiene que se cero.
Prueben hacer el típico listado 10PRINT"hola":GOTO10 . Le dan RUN y corre. Luego prueben poner POKE2048,3 (o sea, que no haya un cero en la posición de memoria $0800) y ya no funciona más.
Acá, como va a haber un listado en $4001, el programa se asegura que la posición de memoria $4000 sea un cero, y no conforme con ello, le da un NEW, como para eliminar cualquier posibilidad de que haya otro listado en esa posición de memoria.

La línea 188 lo que hace es mover la porción de memoria 49152 (o sea, la que antes habíamos llenado con la parte de datas de la sección JOYSTICK) a la zona de $1000
Por eso en un mensaje anterior dije que resultaba raro. Primero llena una posición de memoria, para luego moverla. Parecería más sensato ubicarla allí de entrada. Posiblemente el segundo listado necesite que esté la información por duplicado en las dos posiciones.
Como corresponde, y para emular el comportamiento del cargador al 100%, grabé también esa posición de memoria y le puse el nombre de "MIL"

La línea 189 carga el programa "dragon.prg", o sea, el segundo listado.

La línea 190 llena el buffer del teclado para que le de enter a las instrucciones antes impresas en pantalla y luego RUN.

195 rem datas juego caracteres
200 :


A partir de aquí vienen las datas.

O sea, recapitulemos.
Lo único que hizo el cargador fue llenar posiciones de la memoria y cargar el segundo listado.
Nosotros podemos copiar esas posiciones de la memoria sin necesidad de contar con un programa que las pokee.
Yo lo hice, con los nombres de CHARSET, CODE, JOYSTICK, SCREEN, SCREEN C y MIL
La única modificación al segundo listado fue para incorporar el cambio de color de fondo, mayúscula a minúscula, y un extra: que no se pueda interrumpir mediante RUN/STOP.

Acá adjunto un fichero con todos los archivos involucrados.
Al segundo listado, con la modificación mencionada, lo llamé BASIC

En el exomizer se debe tipear lo siguiente:

exomizer sfx basic,$4001,$7300 code.prg mil.prg charset.prg basic.prg,$4001 joystick.prg screen.prg screen_c.prg -Di_table_addr=$d000 -n

Lo que hago aquí es indicarle al exomizer dónde queremos que arranque el basic en memoria ($4001) y dónde termina el programa, ($7300), ya que allí ubicaremos las variables.
luego aparecen la cantidad de archivos involucrados.
Le indico también que basic.prg sea movidode su posición original $0801, a $4001
-Di_table_addr=$d000 es para mover la "decrunch table", en este caso a la posición $d000, ya que la original quedaba interfiriendo con la zona ocupada por code.prg
Y el -n es para que no haga ningún efecto al descomprimir.

Bueno. Creo que no pasé nada por alto. Así que debería funcionar 100% igual que el programa original.

(nota: ahora recuerdo que para la versión mejorada moví la ubicación de code.prg, que al estar por debajo de la memoria de pantalla, generaba un efecto visual indeseado mientras se descomprimía el archivo. El original debía estar ubicado en $033C y el que les presento está en $0800, que es donde antes estaba ubicado el cargador y no interfiere con nada. La modificación al segundo listado incluye volver a ubicar en su posición de $033C ese sector de la memoria y evitar así la desagradable experiencia de ver caracteres extraños en nuesto monitor durante 3 segundos). :)

Una cosa que se puede hacer es agregar algunas líneas de código al programa para que muestre una pantalla inicial, indicando que fue una iniciativa de Commodore Manía, y los nombres de los involucrados.
Lo único a tener en cuenta es que al agregarle código al programa, hay que calcular el valor de memoria en donde termina el programa (que ahora es $7300), porque si no, no va a funcionar.

26
General / Re:El Castillo del Dragón
« en: Agosto 09, 2015, 02:40:15 »
Por ahí como arranqué diciendo que hice mil pruebas hasta que anduvo, da la sensación de que está atado con alambre. :-)

Lo que pasó fue que al principio lo había encarado distinto. Quise dejar intacto el segundo listado en $4001 e invocarlo con una modificación al cargador en $0801. Eso me tuvo toda la tarde. No funcionaba... Pero después leí el instructivo del exomizer y ví que podía mover el listado a cualquier posición de memoria, e indicarle al programa dónde empieza y dónde termina, y así prescindir completamente del cargador.
Con lo cual es mucho más sencillo y estoy convencido de que funciona igual al original.

Mañana domingo voy a escribir un repaso línea por línea del cargador, para que puedan verificar si no se me pasó nada por alto.

27
General / Re:El Castillo del Dragón
« en: Agosto 08, 2015, 23:31:52 »
Jaja. Estoy viendo que parte del código en basic generó una carita con anteojos.  8)
Son dos caracteres: el primero un 8 y el segundo cierra paréntesis ).

Si tengo tiempo, mañana armo la versión en inglés.

28
General / Re:El Castillo del Dragón
« en: Agosto 08, 2015, 23:26:17 »
Hola. Debería funcionar igual que el original.

Hice una versión mejorada.

Le moví la parte de "código máquina", que al estar debajo de la memoria de pantalla, generaba esos caracteres al descomprimir. Ahora el programa de basic se encarga de mover nuevamente ese sector de la memoria. Y ya no se puede presionar Run/Stop y Restore.  :)

Para eso el código original sufrió una leve modificación:

Las líneas 1 y dos pasaron de ser así:
1 print"“req]Espera 25 segundos...":fort=1to600:next
2 poke53272,31

a así:
1 poke53272,31:poke53280,0:poke53281,0:printchr$(14)chr$(8):poke808,252
2 print"“req]Espera 25 segundos...":fort=0to197:poke828+t,peek(2048+t):next

La 1 pasó a ser la 2 y le agregué la parte donde mueve el "código máquina" y a la 2 (ahora 1) le agregué la definición del color de fondo, cambio de mayúsculas a minúsculas (que originalmente estaban en el cargador) y la imposibilidad de presionar Run/Stop y Restore.

Les dejo la versión mejorada.

Quedó muy prolija.

29
General / Re:El Castillo del Dragón
« en: Agosto 08, 2015, 07:01:59 »
Estuve un buen rato luchando para ver si podía hacer una versión del juego en un solo fichero.

Como siempre ocurre, una vez que entendí cómo funcionaba y supuestamente todo debía ser sencillo, no anduvo y tuve que hace 1000 intentos.

El cargador funciona de la siguiente manera:

Primero genera un juego de caracteres en $3800-$3fff
Código máquina en $033C-$03ff
Joystick en $c000-$c077
Pantalla en $c400-$c7e7
Pantalla color en $c800-$cbe7

(Los nombres figuran en el listado. No se qué función cumplen)

Luego parece copiar la parte de Joystick a $1000-$1077 (medio raro)
Y carga el segundo programa para que arranque en $4001
O sea que quedamos con los dos listados. Uno en $0801 y el otro en $4001.
Si uno interrumpe el juego (original) y pone POKE44,8, va a ver que el listado del cargador continúa en memoria, aunque una parte ha sido pisada al mover Joystick a $1000. POKE44,64 para volver al segundo listado.

Bueno, ahora grabando a disco desde el monitor las partes de código que genera el cargador, y sumándole el segundo listado, podemos prescindir del cargador.... pero me tomó toda la tarde hacerlo funcionar. E hice tantas pruebas que aún ahora no se si lo que hice realmente funciona bien.

Por suerte el exomizer permite arrancar un programa de basic desde otra posición de memoria, pero tuve que mover la "decrunch table" porque interfería donde el programa guarda la parte de "código máquina". Finalmente funcionó. No se por qué la pantalla se llena de caracteres mientras descomprime. Habría que ver si se puede solucionar eso.

Acá les dejo el resultado para que lo testeen.

30
General / Re:Construir un joystick casero tipo arcade
« en: Agosto 06, 2015, 18:35:53 »
Volví. Voy a tratar de leer todos los posteos que me perdí de principios de año a esta parte.

Creo que el Speedking también se comercializaba con otras marcas. Epyx y Wico. Yo tengo uno Wico Ergostick que tengo entendido es igual por dentro al Speedking y realmente es un antes y un después. No lo cambio por nada. La única contra es que está un poco viejuno y tiene más pinta de ratón muerto que de joystick. Incluso al tacto.

Páginas: 1 [2] 3 4 ... 8