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 - na_th_an

Páginas: [1] 2 3
1
General / Mejores Cargas en Cinta
« en: Julio 15, 2011, 12:01:41 »
Cita de: "bovirtual"
¿Y a alguno de vosotros no os pasaba lo de tener la tipica cinta q no cargaba ni a la de tres, y probar a cargarla y salirse de la habitacion, por si acaso el problema eramos "nosotros" mismos?


Ese tipo de cosas pasan porque se perturba el campo chuntey :lol: por eso hay que salir de la habitación, o bailar, o no mirar a la pantalla... depende del juego.

2
General / Mejores Cargas en Cinta
« en: Julio 08, 2011, 13:06:38 »
Cita de: "ckultur"
Ah!!!. Las cintas son realmente uno de los motivos por los que volví a "engancharme" al verdadero C64 y dejar los emuladores.

Lo he comentado con algunos amigos y varias personas coinciden. Personalmente encuentro MUY RELAJANTE cargar de cinta. La música de carga... presentación.... Puedes estar haciendo cualquier otra cosa mientras eso sucede. Muchas veces me "molesta" incluso que el juego haya terminado de cargar así... que reset y A CARGARLO DE NUEVO  :D   En fin.. nadie dijo que todo esto no provocase locura transitoria  :shock:

Respecto a los tiempos de carga.. el otro día cargué en Spectrum +2 los juegos "La abadia del crimen" y Robocop y fué largo de narices. No recuerdo la Abadía... pero el Robocop... Cuando carga la pantalla de presentación ENTONCES sale un contador que empieza una cuenta atras en minutos de MAS DE NUEVE!!! :lol:  :lol:  :lol:

Saludos

Ckultur


Claro, los juegos de 128K solían rondar los 10 minutos. Pero sigue sin parecerme mucho tiempo, teniendo en cuenta que son juegos de 128K :D El tiempo justo para comerte el bocata de nocilla.

3
General / Mejores Cargas en Cinta
« en: Julio 06, 2011, 12:23:17 »
Lo que pasa es que estamos ya acostumbrados a las pantallas "LOADING" de la XBOX 360 y de la PS3, y lo de las cintas a veces es menos tiempo :lol:

Ya en serio, desconozco los bps a los que solían ir las cintas en los C64, pero en Spectrum, cualquier juego de 48K carga en 3 minutos mal contados. Tampoco es tanto.

4
CC65 / Ayuda con el cc65
« en: Junio 28, 2011, 12:39:34 »
Yo y mi incontinencia verbal :lol:

5
CC65 / Ayuda con el cc65
« en: Junio 27, 2011, 12:10:19 »
Básicamente los segmentos no son más que definiciones que emplea el linker para colocar el código ensamblado. Esto, por ejemplo, en un VIC20, es muy necesario, porque la configuración que tiene de memoria no es continua y no puedes colocar lo que te dé la gana donde quieras.

Por ejemplo, si generas ejecutables para un VIC-20 expandido (con 8Kb por ejemplo), los segmentos se emplean para especificar cómodamente qué código va en la RAM principal, dónde se ubica la memoria de color y la de caracteres, y qué código va en la ram expandida.

Por ejemplo, en la configuración de memoria que uso para VIC-20 (bueno, que uso es un decir, porque la "usé" para hacer pruebas pero, por falta de tiempo, lo tengo bastante abandonado), primero se define el mapa de memoria:

Código: [Seleccionar]
MEMORY {
    RAM0: start = $0400, size = $0C00, type = rw;
    RAM:  start = $11FF, size = $0201, type = rw, fill = yes;
    SCR:  start = $1400, size = $0400, type = ro, fill = yes;
    BUF:  start = $1800, size = $0400, type = rw, fill = yes;
    CHAR: start = $1C00, size = $0400, type = rw, fill = yes;
    RAM1: start = $2000, size = $2000, type = rw;
    RAM2: start = $4000, size = $2000, type = rw;
    RAM3: start = $6000, size = $2000, type = rw;
    RAM4: start = $8000, size = $2000, type = rw;
    ROM1: start = $A000, size = $1000, type = ro;
    ROM2: start = $B000, size = $1000, type = ro;
}

Básicamente especifica qué tipo de memoria hay en cada intervalo, cuanto ocupa, y si es de escritura, o de sólo lectura, etc. Luego, sobre ese mapa de memoria, ubicamos nuestros segmentos:

Código: [Seleccionar]
SEGMENTS {
    BASIC:    load = RAM, type = ro, define = yes, optional = no;
    STARTUP:  load = RAM, type = ro, define = yes, optional = no;
    MYCHAR:   load = CHAR, type = rw, define = yes, optional = no;
    CODE:     load = RAM1, type = ro, define = yes, optional = no;
}

Se definen cuatro segmentos: el segmento BASIC y STARTUP se definen en la RAM principal. El segmento MYCHAR, donde irá la definición de mi set de caracteres, se coloca en la zona CHAR. Por último, el segmento CODE se coloca en la ram expandida, o sea, RAM1 del mapa de memoria.

Por último, se define el punto de entrada del autoejecutable:

Código: [Seleccionar]
FEATURES {
   STARTADDRESS:   default = $11FF;
}

Como véis, apunta al principio de la zona RAM.

Luego, en tu código, sólo indicas en qué segmento estás colocando cada cosa. Primero se define lo que hay en el segmento "BASIC", que es código BASIC a pelo. Este código llama al programa en ML:

Código: [Seleccionar]
      .segment "BASIC"

      .word   RUN      ; load address
RUN:   .word   END      ; next line link
      .word   2010   ; line number
      .byte   $9E      ; BASIC token: SYS
      .byte   <(MAIN / 1000 .mod 10) + $30
      .byte   <(MAIN / 100 .mod 10) + $30
      .byte   <(MAIN / 10 .mod 10) + $30
      .byte   <(MAIN / 1 .mod 10) + $30
      .byte   0      ; end of line
END:   .word   0      ; end of program

La directivao .segment "BASIC" lo que hará será ensamblar el código que venga debajo en la zona de RAM donde esté definido dicho segmento.

A continuación se define el código que va en el segmento "STARTUP", que lo que hace es iniciar el VIC y saltar al programa principal, que está en la RAM expandida:

Código: [Seleccionar]
      .segment "STARTUP"
MAIN:
      LDA #$00+$16   ; set for videoram @ $1400 with 22-columns
      STA VIC+$02      ; video matrix address + columns
      LDA #%10101110   ; 8x8 height + 23-rows
      STA VIC+$03      ; rows / character height
      LDA #$DF      ; set video @ $1400 and char table @ $1C00
      STA VIC+$05
      LDA #%01101111   ; Programmer's Reference Guide: Appendix B
      STA VIC+$0F
      LDA #$FF
      STA VIC+$0E   
      .global MTMYSTART   ; useful symbol for MAP and hotkey restarting
      JMP MTMYSTART      ; the entry point into your program

Luego defino mi set de carácteres, en el segmento MYCHAR, que se colocará, tal y como hemos definido, en el lugar correcto:

Código: [Seleccionar]
      .segment "MYCHAR"
SP_PL_R_1:
      .byte   %00000000
      .byte   %00001010
      .byte   %00101010
      .byte   %00101010
      .byte   %00101010
      .byte   %10101001
      .byte   %10100100
      .byte   %00101100
     
      .byte   %00000000
      .byte   %10100000
      .byte   %10101000
      .byte   %10101000
      .byte   %10101000
      .byte   %01010100
      .byte   %01000100
      .byte   %11001100
(etcétera)

Y, por último, poblamos el segmento CODE, situado en la RAM expandida, con el código del juego:

Código: [Seleccionar]
      .segment   "CODE"

MTMYSTART:
      JSR CLEARSCREEN
     
      LDA #2
      STA TX
      STA TY
      LDA #0
      STA TN
      JSR VIC_PSPRITE
(etcétera)

Al ensamblar todo esto, los cachos de código objeto se colocarán en las ubicaciones correctas y todo irá como la seda. Es una forma muy cómoda de organizar la memoria sin tener que hacerlo manualmente generando varios binarios y toda la pesca.

Para un C64 será algo parecido, teniendo en cuenta el mapa de memoria de este sistema.

Haciendo una "adivinación valiente", yo diría que, para el ejemplo del que trata este hilo, bastaría con modificar el fuente para que se pareciese a:

Código: [Seleccionar]
.segment STARTUP
      inc $D020
      jmp $2000
.segment ZPSAVE

Supongo que ZPSAVE (con ZP = ZERO PAGE) será para dar de un plumazo valor a todas las direcciones importantes de la ZP.

6
Desarrollo / Miniproyecto: Programación en Commodore 64
« en: Junio 16, 2011, 13:55:48 »
A mí me gusta el proyecto, la presentación, y la redacción. Sólo corregiría un concepto, cuando dices que "También tiene el inconveniente de que la cabeza azimuth (la cabeza lectora de la cinta magnética) se descalibra y es un infierno recalibrarla."

"Azimuth" no se refiere a la cabeza lectora, sino a la posición de esta. La palabra "azimuth" se usa en el lenguaje inglés como nosotros solemos usar "alfa" para los ángulos. Básicamente lo que tú estás ajustando es el ángulo formado por la cabeza lectora y la horizontal, de forma que desplazas la zona de la cinta de la que se lee, que está colocada de forma perpendicular.

Es por culpa de la expresión típica "ajustar el azimuth", que parece que azimuth se refiere a la cabeza (porque estás ajustando la cabeza), pero en realidad es la posición de la misma. La expresión correcta hubiera sido "ajustar el azimuth de la cabeza lectora", o, mejor "ajustar la posición (o el ángulo) de la cabeza lectora".

Échale las culpas al inglés espagueti de las revistas de la época :D

7
General / Conversor cassettes LIDL
« en: Mayo 16, 2011, 17:00:42 »
Te sale más barato pillarte un cable de audio, enchufar un reproductor de cassette al PC, y usar el Audacity para hacer exactamente lo mismo. Creo que con una inversión de 2 o 3€ lo consigues igual :)

8
Ensamblador / Tutorial de ensamblador de C64
« en: Abril 26, 2011, 13:39:11 »
La página cero son los primeros 256 bytes de RAM. El acceso a esta página por parte de la CPU es "especial" y se realiza muy rápidamente (más rápido que un acceso a otra parte de la memoria - según tengo entendido). Es ideal para usar como "buffer de intercambio" para almacenar datos temporales y tal, ya que la CPU tiene muy pocos registros propios.

La principal utilidad es que hay modos de direccionamientos de la CPU que emplean directamente la "zero page", como puedes ver en el pochocódigo que he puesto más arriba. Las operaciones LD o ST que se refieran a (nn),X o (nn),Y están apuntando a la dirección de memoria obtenida de consultar el valor almacenado en (nn+1)*256+nn y sumarle X o Y. Esto te permite almacenar punteros en la zero page y usarlos directamente para escribir o leer de memoria en bucle.

Por ejemplo, si quieres copiar 100 bytes desde $2000 a $3000, por ejemplo, haríamos así:

[code]
        ; Almacenamos en FC:FB el origen $2000
       
        LDX #$00
        LDY #$20
        STX $FB
        STY $FC         ; FC:FB -> $2000
       
        ; Almacenamos en FE:FD el destino $3000
       
        LDX #$00
        LDY #$30
        STX $FD
        STY $FE         ; FE:FD -> $3000
       
        ; Ahora vamos a copiar 100 bytes...
       
        LDX #$64        ; 100 en hexadecimal

        ; Y esta es la chicha:
       
@b1:    LDA ($FB),X     ; Nos traemos a A lo que esté en ($FB)+256*($FC)+X, o sea, $2000+X
        STA ($FD),X     ; Escribimos A en ($FD)+256*($FE)+X, o sea, $3000+X
        DEX             ; X = X - 1
        BNE @b1         ; IF X <> 0 THEN @b1[/quote]

Lo que viene MUY bien.

Al principio se hace uno un lío con los direccionamientos, pero una vez que le coges el truco te das cuenta de que todo es muy sencillo y está muy bien diseñado. Un 10 para el 6502.

Sólo hay que tener en cuenta que el C64 usa muchas de las direcciones de la página cero para sus cosas, así que si quieres hacer juegos que funcionen bien con las rutinas del Kernel o como se llame tienes que respetarlo. Si, por el contrario, vas a tomar total control sobre la máquina, puedes pasar de ellos.

9
Ensamblador / Tutorial de ensamblador de C64
« en: Abril 25, 2011, 09:23:14 »
Cita de: "Silicebit"
Cita de: "na_th_an"
Si no os importa leer en inglés, tengo un par de libros en PDF sobre ensamblador del 6509 que me han ayudado muchísimo. En un par de días fui capaz de pintar un mapeado de tiles en un VIC-20, ahí es nada :)


¿Qué libros son esos na_th_an? Por cierto, serán del 6502, no del 6509, imagino.  :)

Puede ser que te confundas con el 6809 de Motorola, otro gran y olvidado microprocesador de 8 bits, mejor aún que el 6502 y el Z80 juntos.  :)


Oops, un lápsus de números y memoria :lol: El 2, el 2.

Me ayudó, principalmente, "6502 Machine Language for Beginners", que tenéis online en http://www.6502dude.com/6502/mlb/chapter1.htm . Está todo muy bien explicado.

Luego, el programmer reference guide del VIC-20, que tiene mil y una tablas para que no se te pierda nada. Es específico de este ordenador, pero bueno, yo estaba enredando en este ordenador :D Buscad VIC20PrgRefGuide.txt en Google.

Todas mis pruebas las hice usando el linker y el ensamblador del compilador CC65, que es bastante cómodo para estos manejes (te permite compilar para VIC20 con 8K o 16K de memoria expandida y colocar todo en su sitio: el startup code va el la RAM "normal" y hay una llamada al segmento de memoria expandida donde va todo tu programa. Además, te permite definir un segmento con el juego de caracteres expandido que se coloca en su área correcta de RAM automáticamente. Al final te genera un PRG listo para ejecutar.

Si os interesa el VIC-20 y queréis que os pase todo el "startup code" (que adapté de los fuentes de un juego indie de hace un par de años) no tenéis más que dar un grito :)

En cuanto le pillas el truco a la página cero es genial, es como tener 256 registros por la patilla :D

[code]CLEARSCREEN:
        LDX #$00
        LDY #$14
        STX $FB
        STY $FC         ; FC:FB -> $1400 (character memory)
        LDX #$00
        LDY #$94
        STX $FD
        STY $FE         ; FE:FD -> $9400 (color memory)
        ; 512 vueltas
        LDX #$02
        LDY #$00
@fill:  LDA #$0F
        STA ($FD),Y     ; (FE:FD + Y) <- A
        LDA #$7F
        STA ($FB),Y     ; (FC:FB + Y) <- A
        INY             ; Y ++
        BNE @fill       ; Y != 0 THEN @fill
        INC $FC         ; (FC)++
        INC $FE         ; (FE)++
        DEX             ; X --
        BNE @fill       ; X != 0 THEN @fill
        RTS[/quote]

10
Ensamblador / Tutorial de ensamblador de C64
« en: Abril 19, 2011, 11:49:11 »
Si no os importa leer en inglés, tengo un par de libros en PDF sobre ensamblador del 6509 que me han ayudado muchísimo. En un par de días fui capaz de pintar un mapeado de tiles en un VIC-20, ahí es nada :)

11
Desarrollo / MKII
« en: Febrero 23, 2011, 12:49:11 »
¿Está basado en Forbidden Planet?

12
Nuevos juegos / Nanako en versión física
« en: Noviembre 25, 2010, 12:42:52 »
Es que es una conversión buenísima, la verdad.

13
Nuevos juegos / Nanako en versión física
« en: Noviembre 24, 2010, 18:06:16 »
:lol:  :lol:

14
Nuevos juegos / Nanako en versión física
« en: Noviembre 24, 2010, 15:44:31 »
RuRouNiN: No :(
Bieno: Sí :D

15
Nuevos juegos / Nanako en versión física
« en: Noviembre 24, 2010, 12:57:37 »
Pronto nos dejaremos de ports :)

Páginas: [1] 2 3