descarga NHP2XEX y XEX2NHP?

[WillySoft]

Ésa también es una forma bastante económica de proteger la zona de memoria de intercambio de bancos. Había un juego que hacía eso, que se publicó en la revista Antic. No me acuerdo cómo se llamaba, pero sí sé que se publicó en el último MundoAtari.

[parche]

Listo, revisé uno de mis programas y por ejemplo la primera linea de cainjek dice esto:

if peek(129)<37 then poke 129,37 : run "d:cainjek"

Lo que hace es verificar si la direccion de inicio del basic ya está en la zona alta de la memoria. Si no está, entonces la sube y vuelve a cargar y ejecutar el programa

http://www.atariarchives.org/mapping/me ... hp#128,129

Bien Catrin. Por fin alguien documenta. Cuando estaban posteando todo esto pensaba. Y los que nunca programaron Assembler Atari, como van a cachar que cres.... están poniendo estos compadres?

[WillySoft]

Listo, revisé uno de mis programas y por ejemplo la primera linea de cainjek dice esto:

if peek(129)<37 then poke 129,37 : run "d:cainjek"

Lo que hace es verificar si la direccion de inicio del basic ya está en la zona alta de la memoria. Si no está, entonces la sube y vuelve a cargar y ejecutar el programa

http://www.atariarchives.org/mapping/me ... hp#128,129

Bien Catrin. Por fin alguien documenta. Cuando estaban posteando todo esto pensaba. Y los que nunca programaron Assembler Atari, como van a cachar que cres.... están poniendo estos compadres?

Habló el que más documentaba... Verdad que guardó los fuentes del NHP y no tuvo que pedirlos a otro, ¡Ja!
::jua ::jua ::jua

[xt5]

Listo, revisé uno de mis programas y por ejemplo la primera linea de cainjek dice esto:

if peek(129)<37 then poke 129,37 : run "d:cainjek"

Lo que hace es verificar si la direccion de inicio del basic ya está en la zona alta de la memoria. Si no está, entonces la sube y vuelve a cargar y ejecutar el programa

http://www.atariarchives.org/mapping/me ... hp#128,129

Bien Catrin. Por fin alguien documenta. Cuando estaban posteando todo esto pensaba. Y los que nunca programaron Assembler Atari, como van a cachar que cres.... están poniendo estos compadres?

Y los que empezamos el año pasado simpre nos preguntamos porque cres.... usaban numeros decimales y no hexadecimales para las direcciones y valores de los registros... casi todos los programas y documentaciones estan en decimal, es lo mas anti-natural que puede haber.

Suppawer, apenas tengo un tiempo lo hago, tal vez podria hacer algo mas generico incluso

[WillySoft]

Listo, revisé uno de mis programas y por ejemplo la primera linea de cainjek dice esto:

if peek(129)<37 then poke 129,37 : run "d:cainjek"

Lo que hace es verificar si la direccion de inicio del basic ya está en la zona alta de la memoria. Si no está, entonces la sube y vuelve a cargar y ejecutar el programa

http://www.atariarchives.org/mapping/me ... hp#128,129

Bien Catrin. Por fin alguien documenta. Cuando estaban posteando todo esto pensaba. Y los que nunca programaron Assembler Atari, como van a cachar que cres.... están poniendo estos compadres?

Y los que empezamos el año pasado simpre nos preguntamos porque cres.... usaban numeros decimales y no hexadecimales para las direcciones y valores de los registros... casi todos los programas y documentaciones estan en decimal, es lo mas anti-natural que puede haber.

Suppawer, apenas tengo un tiempo lo hago, tal vez podria hacer algo mas generico incluso

La verdad, antes ocupaba los valores en hexadecimal, pero como he perdido la práctica de programar en ASM, utilicé los valores en decimal, según el Mapping The Atari.

Bueno, algunos comentarios de posiciones de memoria:

212, 213 = $D4, $D5 = FP0 : Se utiliza como valor de retorno al Basic de Atari, de modo que hubiere un resultado de ejecutar la rutina.

54017 =$D301 = PORTB : controla el Basic en memoria, más el uso de la zona de RAM bajo la ROM del Atari, además del switcheo de bancos para el caso del 130XE en la zona de memoria $4000-$7FFF en hexadecimal.

Saludos.

[parche]

Viste que puedes Willy?

Ahora que hablamos todos español, porque no usar direcciones relativas en torno a la dirección $0600 (1536 dec) como lo hacíamos en aquellos tiempos para que administre los bancos de memoria?

Esa era como la dirección típica cuando ejecutabas algo en Basic.

[vitoco]

Je, je, je... la rutina en ASM del Willy hace lo mismo que mi ciclo FOR, claro que no puse en mi otro post el segundo FOR que lee los bytes grabados en 16384 en cada modificación de PORTB y los compara con lo esperado.

Cambiando mis FOR por el USR de Willy no gano los bytes necesarios para resolver el problema de fondo: mi programa carga muy arriba bajo el área de paginación de memoria.

Tampoco puedo pasar el código a la memoria superior del la ventana de acceso como sugiere Franco, porque tiene menos RAM disponible que la de abajo (el BASIC y la pantalla juntos ocupan más de 9K versus las páginas 0 a 6 y el DOS ocupan a lo más 8K).

@fcatrin: me suena raro el valor 37 en el poke del LOMEM, eso está bajo el banco de swap, y apenas sobre DOS (el 2.5 me deja MEMLO con 31). El banco de swap está entre 64 y 127, por lo que tu valor debiera ser al menos de 128. Pienso que lo que estás haciendo con tu IF es reservando unas 6 páginas para el buffer de CAIN que va a dar como bloque al cassette.

Lo que estoy tratando de cachar es por qué no me alcanza la memoria en el emulador para el SITRE. Como dije antes, es probable que usara algún DOS que dejaba el MEMLO en algún valor menor a 31 ($1F). Es raro, porque el Mapping dice que debiera ser 28 ($1C)

Recuerdo que SITRE utilizaba los 4 bancos extra, más el original, más lo que alcanzara a estar disponible en el banco siguiente bajo el BASIC y la pantalla. El banco de RAM extra de los XL/XE no la podía usar porque había que modificar cosas de la ROM, por lo que ésta se copiaba a esa RAM. Claro que normalmente los XEX de los juegos ocupaban menos de 64K y los 4 bancos bastaban.

++Vitoco

PS: Bueno, ahora puse algunos links a los conceptos discutidos ;-)

[fcatrin]

Creo que estas en lo correcto vitoco. No recuerdo por qué usaba ese valor, probablemente para reservar un espacio sobre el DOS y ahi cargar algunas cosas. Y el valor estaba calculado sobre el DOS que usaba en ese tiempo (2.5?)

[WillySoft]

Je, je, je... la rutina en ASM del Willy hace lo mismo que mi ciclo FOR, claro que no puse en mi otro post el segundo FOR que lee los bytes grabados en 16384 en cada modificación de PORTB y los compara con lo esperado.

Cambiando mis FOR por el USR de Willy no gano los bytes necesarios para resolver el problema de fondo: mi programa carga muy arriba bajo el área de paginación de memoria.

Tampoco puedo pasar el código a la memoria superior del la ventana de acceso como sugiere Franco, porque tiene menos RAM disponible que la de abajo (el BASIC y la pantalla juntos ocupan más de 9K versus las páginas 0 a 6 y el DOS ocupan a lo más 8K).

@fcatrin: me suena raro el valor 37 en el poke del LOMEM, eso está bajo el banco de swap, y apenas sobre DOS (el 2.5 me deja MEMLO con 31). El banco de swap está entre 64 y 127, por lo que tu valor debiera ser al menos de 128. Pienso que lo que estás haciendo con tu IF es reservando unas 6 páginas para el buffer de CAIN que va a dar como bloque al cassette.

Lo que estoy tratando de cachar es por qué no me alcanza la memoria en el emulador para el SITRE. Como dije antes, es probable que usara algún DOS que dejaba el MEMLO en algún valor menor a 31 ($1F). Es raro, porque el Mapping dice que debiera ser 28 ($1C)

Recuerdo que SITRE utilizaba los 4 bancos extra, más el original, más lo que alcanzara a estar disponible en el banco siguiente bajo el BASIC y la pantalla. El banco de RAM extra de los XL/XE no la podía usar porque había que modificar cosas de la ROM, por lo que ésta se copiaba a esa RAM. Claro que normalmente los XEX de los juegos ocupaban menos de 64K y los 4 bancos bastaban.

++Vitoco

PS: Bueno, ahora puse algunos links a los conceptos discutidos ;-)

Hace lo mismo, pero resuelve el tema de fondo, ya que guarda la posición 16384 a su valor original, sin modificar lo almacenado en el programa BASIC. Ésa es la gracia de usar lenguaje de máquina. Nada más, pero tampoco menos.

Saludos.

[vitoco]

Hace lo mismo, pero resuelve el tema de fondo, ya que guarda la posición 16384 a su valor original, sin modificar lo almacenado en el programa BASIC. Ésa es la gracia de usar lenguaje de máquina. Nada más, pero tampoco menos.

En realidad da lo mismo lo que haya en cada banco en esa dirección, si igual voy a poner ahí la data a transferir al cassette.

Bajé el LOMEM a mano a 29 para ganar medio kilo y volví a cargar y correr mi copiador. Pasó OK el FOR, cargó un juego seleccionado en los bancos, pero no pudo grabarlo en el .CAS

Por alguna razón, mi llamada desde un USR a SIOV no hace su pega. Sólo logré poner el primer bloque en el .CAS, con un "PRINT #2", pero los restantes que van por el USR son ignorados. Es más, el emulador queda piteando incluso después de haber hecho un "SOUND 0,0,0,0" al final del proceso de grabación...

Como esta parte del grabador está toda en lenguaje de máquina, me va a tomar un resto recordar qué hacía cada rutina. El programa en BASIC tiene 9 strings distintos de rutinas en assembler que se llaman con USR, sin incluir los 3 del cargador!!! No he encontrado los .ASM o .M65 de ellos. Capaz que los haya hecho a mano

++V

[WillySoft]

Hace lo mismo, pero resuelve el tema de fondo, ya que guarda la posición 16384 a su valor original, sin modificar lo almacenado en el programa BASIC. Ésa es la gracia de usar lenguaje de máquina. Nada más, pero tampoco menos.

En realidad da lo mismo lo que haya en cada banco en esa dirección, si igual voy a poner ahí la data a transferir al cassette.

Bajé el LOMEM a mano a 29 para ganar medio kilo y volví a cargar y correr mi copiador. Pasó OK el FOR, cargó un juego seleccionado en los bancos, pero no pudo grabarlo en el .CAS

Por alguna razón, mi llamada desde un USR a SIOV no hace su pega. Sólo logré poner el primer bloque en el .CAS, con un "PRINT #2", pero los restantes que van por el USR son ignorados. Es más, el emulador queda piteando incluso después de haber hecho un "SOUND 0,0,0,0" al final del proceso de grabación...

Como esta parte del grabador está toda en lenguaje de máquina, me va a tomar un resto recordar qué hacía cada rutina. El programa en BASIC tiene 9 strings distintos de rutinas en assembler que se llaman con USR, sin incluir los 3 del cargador!!! No he encontrado los .ASM o .M65 de ellos. Capaz que los haya hecho a mano

++V

Es que, por lo que estoy entendiendo, al modificar la posición 16384 modificas el programa BASIC también, lo que te corrompería la ejecución.

En todo caso, saldría más económico hacerlo todo en ASM, y te olvidas de qué posiciones ocupar o no ocupar. No creo sea difícil de implementar eso.

Saludos.

[WillySoft]

Viste que puedes Willy?

¿A qué te refieres con la posición que "todos utilizamos"?

Vamos, ¡¡tú también puedes!!

[vitoco]

Es que, por lo que estoy entendiendo, al modificar la posición 16384 modificas el programa BASIC también, lo que te corrompería la ejecución.

El programa carga bajo esa dirección, pero usa como 2K en variables string (entre ASM y datos), y eso es lo que se superpone al banco por un par de páginas. Todavía no pillo que DOS usaba con SITRE que dejaba más memoria disponible.

En todo caso, saldría más económico hacerlo todo en ASM, y te olvidas de qué posiciones ocupar o no ocupar. No creo sea difícil de implementar eso.

Fueron pocos los programas que hice 100% en assembler.

Yo tenía la costumbre de programar la columna vertebral en BASIC, pero plagado de rutinas en assembler. Y cuando apareció el TurboBASIC, gualá... (pero sólo en un par de excepciones incorporé alguna de las nuevas instrucciones a mis programas).

Así era más fácil el debuggeo, además que muchas rutinas eran recicladas y las tenía en un disco en formato .LST:

Código: Seleccionar todo

1 DIM IO$(33)
2 IO$="hh%&Yh+*h/%&h$#?hh#&/%h$/&h$/¿|=hh*LSd"
3 U=USR(ADR(IO$),P1,P2,P3)

Bastaba hacer un ENTER "D:IO.LST", listar filas de 1 a 9 y renumerar a gusto, aunque no siempre los LST tenían el DIM o el ejemplo de USR. Por si acaso, nunca usaba números de línea menores a 100 en mis programas, y la 100 siempre era un REM con los créditos y un ESC-ESC+CTRL-W para configurar la impresora.

Así era súper rápido generar utilitarios...

El problema es que los strings con ASM ocupan el doble de espacio: el DIM y la asignación. Esto puedo reemplazarlo para algunos casos por:

Código: Seleccionar todo

1 IO=ADR("hh%&Yh+*h/%&h$#?hh#&/%h$/&h$/¿|=hh*LSd")
2 U=USR(IO,P1,P2,P3).

o, cuando sea posible, tan sólo por:

Código: Seleccionar todo

1 U=USR(ADR("hh%&Yh+*h/%&h$#?hh#&/%h$/&h$/¿|=hh*LSd"),P1,P2,P3).

En el caso de SITRE, creo que sólo puedo ahorrar poco más de una página (256 bytes) con este método. El problema es que varias rutinas son de más de 130 bytes y no puedo representarlas como sólo una línea de BASIC, y debo concatenar en caliente los trozos de la rutina.

Otra alternativa sería usar la técnica del LOMEM de CAIN que dijo Franco y dejar los ASM fuera del BASIC.

Por ahora, tengo que cachar por qué mi rutina CSIO$ no graba en el .CAS

++Vitoco

[fcatrin]

Yo usaba un hibrido. Algunas rutinas las tenia como string, las mas obvias. Otras cosas como por ejemplo el código del cargador lo cargaba de disco.

Eso era más que nada por comodidad, ya que las rutinas mas largas las hacía con el ensamblador, y las mas obvias las manejaba con string y seguramente algun tipo de copy / paste entre programas basic.

[WillySoft]

Yo al principio utilizaba BASIC, con rutinas en lenguaje máquina. Después me fui derecho al assembler. Al final, te das cuenta que te demoras casi lo mismo, sobre todo al reutilizar rutinas.

Un ejemplo fue el grabador de eprom que hicimos con el Z. el software al final lo hice de puros elementos separados, reciclados.