Retronia

Estaba revisando otros topis donde hay cosas parecidas, la idea es crear un loader, realice la siguiente prueba con resultados positivos. pero es algo básico, como guía lo que enseña franco. cargador de signo con exclamación.

Lo primero cree el asm con mac65
prueba
Como se aprecia en el código, es una rutina simple que solo coloca la pantalla en negro, con un bucle a $06C0, luego ocupo los archivos que vitoco usa para la creación de usr DESCOMPRESOR BINARIO MAC65 Y STRING.BAS, luego de tener el asm limpio le agrego la cabezera en chr$, que es 00 01 00 06 0E 06, y al final E0 02 E1 02.

en basic quedaría así
hasta ahí todo bien, pero he buscado la manera de usar el dli
le sumo 00 01 00 06 57 06 y al final E0 02 E1 02



hago el mismo proceso al anterior y me sale boot error o se cuelga altirra.
¿Cual sería el error que estoy cometiendo?.

Gracias de antemano.

NOTA: El basic solo lo uso para probar.

.... nunca dejes de postear, mantén viva a la comunidad aunque tengas la respuesta a la mano ....

Veo varios errores...

dogdark escribió:Lo primero cree el asm con mac65
prueba

Código: Seleccionar todo

0000                0120     *=  $0600
0600 A900        0130     LDA #0
0602 8DC602    0140     STA 710
0605 A90E        0150     LDA #14
0607 8DC502    0160     STA 709
060A A200       0170     LDX #0
060C C000       0180     CPY #0
060E F0FC       0190     BEQ $060C

*** ASSEMBLY ERRORS: 0   25109 BYTES FREE

LDX #0 pone en cero el registro X de la CPU, y CPY #0 compara el valor del registro Y con cero. Una cosa no tiene que ver con la otra, y viendo que después haces un BEQ loop pienso que el LDX debió ser LDY para que quede en bucle infinito. Así como está, dependerá del valor actual de Y, y de seguro que no es cero, pasando de largo a la siguiente dirección de memoria. Si ahí hay basura que la CPU no puede interpretar como instrucciones válidas, Altirra va a abortar.

dogdark escribió:Como se aprecia en el código, es una rutina simple que solo coloca la pantalla en negro, con un bucle a $06C0, luego ocupo los archivos que vitoco usa para la creación de usr DESCOMPRESOR BINARIO MAC65 Y STRING.BAS, luego de tener el asm limpio le agrego la cabezera en chr$, que es 00 01 00 06 0E 06, y al final E0 02 E1 02.

El descompresor binario no aplica para programas pequeños que ocupan menos de una página de memoria (256 bytes), ya que obtendrás como resultado lo mismo que ya tienes.

Por otro lado, el programa STRING le saca los 6 primeros bytes de cabecera al binario, ya que el objetivo es usar el programa ensamblado como una rutina USR dentro del BASIC y no se necesitan las cabeceras. Como en tu caso sí necesitarías las cabeceras porque las vas a poner en un archivo en disco, en vez de agregarlas manualmente, bastaría modificar el programa STRING.BAS para que no se salte los primeros 6 bytes del archivo que lee. Ojo que si el archivo de entrada ya trae bytes adicionales como el vector de inicio para un XEX, también los incluirá en el string para BASIC.

En tu caso no estás haciendo un XEX sino que un BOOT loader, por lo que lo que dije en el párrafo anterior no aplica (Mac/65 genera estructuras OBJ que en la práctica son XEX), y sí es necesario agregar los 6 bytes adicionales para registros tipo BOOT. El problema aquí es que los valores que pusiste NO son correctos, ya que la estructura es:

1 byte: (00) no utilizado por el sistema.
1 byte: (01) cantidad de bloques consecutivos a leer.
2 bytes: (00 06) la dirección de memoria para almacenar este 1er bloque incluyendo estos 6 bytes de control.
2 bytes: (06 06) el vector de inicio para pasar el control cuando se hayan cargado todos los bloques.

Los valores entre paréntesis son los de tu caso, y mira los valores que puse en los 2 últimos: no son 00 06 ($0600), sino que 6 bytes después ($0606), y por lo tanto es el valor que deberías tener en la línea 120.

Alternativamente podrías cambiar la línea 120 por este bloque para no tener que agregarlos a mano en el BASIC: Si ya tenías definida una etiqueta que indica en qué parte de la memoria cargar, la pones en vez de $0600 en ese bloque. Así se hace más fácil cambiar después por $0700, que es donde por convención cargan los loaders.

Lo que sí está demás son los 4 bytes que agregaste al final. Eso es válido sólo para los XEX, y debieran ser 6 bytes. Si tu programa fuera un XEX, serían los valores E0 02 E1 02 00 06.

Por último, en la línea 300 dice .BYTE $43. Esa corresponde a una línea en modo gráfico 0 de 10 pixeles de alto que requiere de 40 bytes de datos. Como tu LINEA1 tiene solo 20 bytes, pienso que quisiste decir $46 para modo 1 o $47 para modo gráfico 2. (el $40 sumado está bien porque agrega la información de dónde se encuentra la data).

Ojo que a la data de LINEA1 debes sumarle o restarle 32 bytes a cada caracter, ya que lo que el DL espera son códigos internos, no el ATASCII puro. Hay un enroque entre las mayúscoulas, los caracteres de control y los números y símbolos.

Un detalle: agrega la línea 225 y cambia la 240 para que el bucle quede relocalizable (¡se va a mover 6 bytes!): Otra cosa: no estoy seguro si es motivo para BOOT ERROR al cargar, pero creo que A$ debe medir exactamente un múltiplo de 128 bytes al grabar a través de CIO (con PRINT #1), es decir, además de cambiar el DIM, debes rellenar A$.

Cuéntanos cómo te va...

Voy a leer detenidamente lo que me enseña vitoco, creo que me has aclarado bastantes dudas con respecto a la información que obtuve del foro y de la web de catrin, lo otro en realidad me pegue el pastelazo con el ldx, quería decir ldy, para hacer la comparación para así realizar el bucle. Seguiré tus consejos, ya que estaba creando el close y el open que ya están listos. No quiero usar macros ya establecidas, si no que personalizadas. Como le decía, el basic solo lo uso como método de prueba, por que necesito cargar los datos en el boot loeader en 3 partes, dos bloques de 128 bytes y el tercero de 250 y si me faltan bytes un cuarto bloque. Eso tengo que armarlo en asm para grabar el put. Ya teniendo el put en mi asm, me olvido de basic y sigo con todo en mac65. Un abrazo Maestro y gracias por su paciencia y ayuda.




.... nunca dejes de postear, mantén viva a la comunidad aunque tengas la respuesta a la mano ....

Ojo que dejé varios detallitos sin mencionar, para que los descubras y resuelvas en el proceso. Eso es parte del aprendizaje.

Ya los sabes viejo perro... para cualquier consulta que tengas, aquí estaré.

Gracias maestro Vitoco, grande Papa, con el tiempo que he dedicado a estudiar ya por lo menos comprendo cuando me explicas las cosas, ya estoy a otro nivel, aunque me falta mucho aún.

Para que explicar cual es la idea, si ya de tanto preguntar en varios temas, usted ya sabe para que es, lo que estoy armando.



realice los cambios pertinentes, como el código es mas largo, se ocupan 2 bloques. por lo tanto
la linea 122 el byte $01 lo cambie por $02 y la posicion a $0700

más el cambio de caracteres que los modifique con el traductor.

lo único que me falto preguntar. si hay 3 bloques, 1 y 2 con este código y un tercero con otra data, hay posibilidad de que se ejecuten las datas de los 2 primeros bloques antes que se cargue el tercero?

como para dejar esta presentación antes de cargar los próximos 1 o 2 bloques que restan?

Nota: dejo el cas adjunto para muestra.


.... nunca dejes de postear, mantén viva a la comunidad aunque tengas la respuesta a la mano ....

Cuando estás en boot no se hace nada hasta que se termina la carga, por lo tanto ningún bloque se ejecutará sino hasta llegar al fin del archivo (EOF).

El boot generalmente es un cargador de otro sistema de carga más complejo, en la gran mayoría de los casos un cargador de XEX.

Una de las gracias de XEX es que ese formato sí te permite ejecutar cosas entre medio. Después de cargar cada bloque se ve si hay una dirección válida en $2E0. Si la hay, se detiene la cinta y se ejecuta el código apuntado por ese vector (o puntero). Es por eso que los copiadores dejaban un IRG más largo en ese caso, ya que el motor se demora un poco en detenerse o partir, entonces un IRG más largo aseguraba que al momento de partir, aun no hubieran datos para leer.

Te recomiendo darle un vistazo a esto también:
https://www.dropbox.com/s/lxhnbvsdnlkqv ... e.pdf?dl=0

Saludos!

Muchas gracias Franco le echare un vistaso. Me servirá bastante.

Franco ya respondió, y además dejó un excelente material para que planifiques lo que sigue:

fcatrin escribió:Te recomiendo darle un vistazo a esto también:
https://www.dropbox.com/s/lxhnbvsdnlkqv ... e.pdf?dl=0

Pero ya sabes... si tienes dudas, consulte no'más!

Ahora que ya tengo los dos diseños que voy a usar, paso a realizar mis consultas pertinentes, me voy a referir a dos copiadores Cain y sitre, ambos con 2 bloques de inicio pero diferentes en código.

1-. En ambos después del segundo bloque se activa el stac.
SITRE-. aprecié que en el primer bloque es de información que son 100 bytes (variable C4$ en sitre, 100 bytes info, 28 bytes $00 ), y en el segundo estaría la ejecución del stac,131 bytes(variable C3$ 1 al 59 código, 60 al 131 bytes $00), código que debo desamblar para ver como funciona la carga posterior del 3 bloque y 4.
CAIN-. primer bloque utiliza 19 bytes cabecera con en algunos $00 en STA, después vienen 109 bytes que no logre entender, porque no son iguales siempre, me parece que son bytes de relleno para evitar la anticopia, y 128 bytes posterior donde se encuentra el activador stac y apagado de pantalla, código a desamblar.
Ambos en el primer bloque terminan en RTS.

PRIMERA PREGUNTA- El RTS siempre va al final de cada código puesto para terminar un proceso y pasar al siguiente, que por lo que veo sigue en el segundo bloque en otra posición.

Ejemplo

bloque 1
*=$0700
LDA #$00
STA 559
RTS

BLOQUE 2
*=$2000
LDA #$00
STA 710
.....
RTS

SEGUNDA PREGUNTA, Cuando desamble el segundo bloque en ambos, esta data que hay aca, me genera la velocidad(sistema stac), de carga, cantidad de bytes a cargar en el 3 4 y 5 etc bloques, y código de portada de carga mas data, nombre, titulo, pitos lentos, corrector de errores?.

Después hago la otra pregunta, a lo que me respondan, se los agradesco de antemano.

PD: La estructura esta en basic, y los bloques los estoy haciendo en mac65 y pasados a basic con los programas de vitoco. la presentación y carga de archivos a memoria esta terminada. estoy con la etapa de grabacion del boot loader.

ADJUNTO MODIFICACION AL POST

Primero haré una observación relevante que no sé si tienes clara:

Todos los bloques estándares de cassette pesan 131 bytes cuando son grabados usando CIO. Estos corresponden a:

- 2 bytes con valor $55 de sincronización y ajuste de velocidad (secuencia de 1s y 0s)
- 128 bytes de datos (los datos que están en C4$ del grabador SITRE)
- 1 byte de checksum (calculado por la rutina CIO en el vector CIOV al momento de grabar y validado al leer)

En el caso de SITRE, el primer bloque se graba con CIO estándar y por eso se envían 128 bytes de C4$ utizando un vulgar print #2;C4$;, pero en el segundo bloque, la grabación no se hace utilizando CIO, sino CSIO mediante una rutina USR, y que trae incluido los 2 bytes de sicronización "UU" ($55,$55) y el byte de checksum (131 bytes en total almecenados en C3$).

Este segundo bloque no trae rutinas STAC, sino que tiene la finalidad de hacer que el Atari dé por terminada la carga del juego (algo así como anticopia). Es un registro EOF ficticio, que en lugar de estar en blanco, contiene esos cincuentaytantos bytes que realizan la carga del primer bloque de SITRE (C2$), el cual fue grabado en cinta a través de CSIO también, pero con la frecuencia ya modificada para dar mayor velocidad de grabación (y posterior lectura), y el largo también ya dejó de ser 133 bytes, en este bloque sólo está la parte que se muestra en pantalla durante la carga del juego, pero es totalmente descartable. La rutina STAC de SITRE viene en el cuarto bloque (segundo de SITRE en C1$), que asume que el la etapa anterior está ahí, pero si ya no está porque el XEX pisó esos datos (página 6=$0600), da lo mismo, pero así se consigue un código más reducido de LOADER en página 7=$0700, compatible con la gran mayoría de los XEX.

Ojo que el loader de SITRE no "genera" velocidad, y ni siquiera comprueba velocidad... eso le da lo mismo, ya que fue la rutina estándar CSIO en la ROM la que leyó el bloque en memoria a la velocidad que fue grabado (usando los 2 bytes $55 para sincronizar los BAUD). Fue durante la grabación de la cinta que se modificó la rutina CSIO copiando la ROM a la RAM y haciendo unos pocos POKE con valores ajustados para cambiar la frecuencia de la señal, aumentar la tasa de transferencia y disminuir las pausas. Por lo tanto, el loader de SITRE sólo toma la data recibida de la rutina CSIO y sólo valida que sea el bloque que esperaba de acuerdo a la numeración asignada, y si CSIO indicó que el bloque es inválido, hace lo de "devolver la cinta 3 vueltas" para reintentar. El resto en ese bloque de C1$ es lo tipico de un loader de XEX.

Que yo recuerde, en ninguna parte SITRE le devuelve el control a la rutina de booteo, es decir, no hay un RTS efectivo. Si los ves ahí, estaban para confundir a los curiosos

Espero con eso haber respondido, al menos en parte, tus dudas.

Voy a tratar de complementar la info provista por Vitoco. Me enfocaré en el bootloader, que es lo primero que se carga.

Para empezar, todos los bloques de carga estándar siguen la estructura que describo en la página 6 del PDF AtariTape. En condiciones normales el último bloque (EOF) va relleno de puros ceros. Cuando usas las rutinas de la BIOS para cargar un archivo de cinta a memoria, ese último bloque nunca se transfiere a memoria porque se asume que viene vacío.

En los boot loaders de CAIN y seguramente SITRE este ultimo bloque se graba con datos. Es un pequeño truco por si alguien trata de copiar el boot loader con la rutina de la BIOS, en ese caso siempre le faltarán los bytes que vienen en el EOF porque se asumen que no llevan datos. Aún así, este bloque queda en el buffer de carga de cassette en $700 por lo tanto es usable.

Qué es lo que va en ese ultimo bloque? Justamente ahi va el código ejecutable del boot loader, o al menos la parte inicial. En los archivos que te compartí puedes ver el "fuente" en CAIN.260.txt. Lo que hace ese código es cargar un siguiente bloque y además lleva el nombre del juego y una marca no utilizada que dice FRANCO CATRIN.

Ahora, esa parte no es como la recuerdo. Si puedes grabar un video con una carga de CAIN me gustaría escuchar los bloques para estar seguro de cómo funciona.

Saludos!

Mas menos tengo clara la película, solo estoy con el problema y duda que no he podido resolver, por ejemplo, para el primer bloque solo hago un apago de pantalla en $0700, con LDA #0 STA 559 que termina en un loop,y una presentación en $2000 que va desde el bloque 2 hacia adelante que también termina con un loop para que se vea, como lo hago para anexar ambas, obiamente le quite el loop al apagado, se cuelga ahí y no continua la carga, use tu ejemplo CAIN190.TXT, que modifique para lo que quiero.
se apaga al cargar el segundo bloque pero no sigue cargando los demás datos. pero en el segundo bloque esta grabado el nuevo código que empieza desde el $2000
El primero en basic lo tengo como a$(CON 128 BYTES, apagado de pantalla)que se graba en el primer bloque y el segundo como blk$(516 bytes aprox),que se empieza a grabar en el segundo bloque.

Lo siguiente dejo los videos de cain para que los observe.





Lo otro que estuve jugando también un poco fue con los pokes para acelerar el ingreso de bytes o sea sistema stac, tampoco logre descifrar definitivamente como se activa.

Ojo que la dirección ejecutable $2E0 es sólo para XEX. Esa parte estaría de más.

Para entender lo que pasa acá hay que entender cómo funciona el boot de cassette.

En el boot de cassette se lee una cabecera que contiene 3 datos importantes: El número de bloques, la dirección de carga de los datos (llamémosle START) y la dirección de ejecución del boot (llamémosle EXEC). Hay algo que no es tan obvio y es que este proceso es un boot en dos partes, primero se ejecutará START y luego EXEC. Haciendo una simplificación muy extrema la BIOS hace básicamente esto:

JSR START
JMP EXEC

Si miras el cain.190.txt la cabecera indica START=$700 y EXEC=$400. Y aquí viene una parte truculenta anti copia:

En el primer bloque van los datos que se cargan en START, y como no hay nada más, esa es la razón por la que el resto de los datos de ese bloque no importan.

El segundo bloque que se carga es el EOF y es en donde viene el código real. Al terminar la carga de ese bloque, los datos quedarán en $400 y aha! EXEC=$400. Ahi se ejecuta el código de cain.260.txt

Donde está tu problema?

En tu código, START = $700 y EXEC = APAGO que también vale: $700. Entonces sucederá algo como esto:

JSR $700
JMP $700

Por eso no se ejecuta nada más.

aaahhh!!!, claro yo me estaba siguiendo por los datos 1-. de tu web por lo de los xex, y segundo por lo de la info que me enviaste en pdf, por eso tenia el enredo, el error mio era más simple de lo previsto, estaba colocando código xex en un boot loader, por eso nunca me iba a funcionar, mas encima estaba mal redirigiendo, pal día del ñeuque , ya codificare todo de nuevo y redireccionaré como corresponde. gracias por el dato.
este era el código que tenia para los primeros 256 bytes. por eso nunca funcionaria. incluso había eliminado la sección del loop y ahí todo quedaba en boot error o se colgaba, etc etc. Todo en $0700.

Después de varios dias de trabajo de ensamble, desamble de códigos, entendimiento de procesos, el comprender lo que me decian Vitoco y Franco, el probar, aprender de error y fallos que son los que te demuestran despues de horas darte cuenta en que te equivocaste y volver a leer y enteder cual fué el error, ya tengo el 90% de mi boot loader para casette, el 10% restante aun lo estoy estudiando porque se cargan casi 700 bytes en la posicion $0700, debo de estudiar bien como cargar esos bytes que son en un solo bloque, porque los códigos de muestra solo te permiten cargar hasta 256 (0-255).
Dejo un videito de demo para mostrar como esta quedando la cosa que hara otra cosa que permitira cargar una cosa.

Revisa el archivo cain 260, ahí utiliza una rutina de la BIOS para cargar un bloque de largo arbitrario en una posición de memoria arbitraria.

La tabla descriptor contiene las instrucciones para la BIOS, el código simplemente copia esas instrucciones en la ubicación que la BIOS requiere y llama al servicio.

Agregué los comentarios al archivo que dejé en dropbox
https://www.dropbox.com/s/vq8he95jax41h ... 0.txt?dl=0

Para grabar un bloque es lo mismo, solo que cambia esta parte:

; 82 = load block
; 64 = read data

por (puedo estar equivocado)

; 80 = save block
; 128 = write data

Saludos!

Muchísimas gracias Franco por la descripción del código, yo lo miraba y lo miraba, y me decía a mi mismo, mismo acá se debe picar, este debe servir, a lo igual que el que usa Vitoco (CSIOV), que había que aplicar el BL y el BH para decrementar los bytes entrantes en la posición deseada y después llamar el inicio desde donde comienza el tercer bloque en mi caso.

¿El restante bytes desde Catrin hacia abajo, no tienen relevancia alguna con los demás?, haré las pruebas, y les cuento, por que estoy desamblando otro código tuyo, que es mas rápido de lectura aun, pero en estructura son todos iguales, me refiero a portadas cain hasta cainjek, cambian algunas cosas pero las ideas son casi las mismas.

dogdark escribió:¿El restante bytes desde Catrin hacia abajo, no tienen relevancia alguna con los demás?

No, el resto hacia abajo es puro relleno

dogdark escribió:haré las pruebas, y les cuento, por que estoy desamblando otro código tuyo, que es mas rápido de lectura aun, pero en estructura son todos iguales, me refiero a portadas cain hasta cainjek, cambian algunas cosas pero las ideas son casi las mismas.

Si, en general todos usan la misma idea como base. El único que cambia harto es CAIN III (el de la parabólica), pero es sólo por la animación. Habrá algún video de ese cargador?

Saludos!

A pedido Vuestro maestro Franco

CAIN V2



CAIN V3



CAIN INJEKTOR

BLOKE1



BLOKE2



publico los dos primeros bloques porque me resulto el siguiente problema. si notan en el primer bloque esta la pantalla que se mostrara cuando el segundo bloque alla terminado de cargar, hasta ahi no tengno problema alguno cuando en el segundo bloque dejo con un loop este se aparece en la pantalla.

loop
ldy #0
cpy #0
beq loop

el problema es cuando coloco el codigo que aparece en la foto 2 de bloke2, que supuestamente debe de cargar en este caso mio, 257 bytes en la poscion de memoria $2000.

Cual es el problema, cargan los dos bloques y no carga mas. ahi se queda, probe con los codigos de cain pasandolos a mi basic de prueba y tampoco me carga el tercer bloque.

el tercer bloque es casi lo mismo que el primero pero con mas lineas y referido a la posicion de memoria $2000.

la manera de cargarlos

? #1;bloke1$;
? #1;bloke2$;
y aca ocupo la rutina de vitoco csiov
U=USR(CSIO,D,ADR(BLOKE3$),257)

y no carga el tercer bloque