Retronia

Publicado: **Vie Feb 20, 2015 11:33 pm**

SITRE es un copiador de juegos de disco a cassette para Atari 8-bits que desarrollé durante el verano de 1989 a pedido de SYFCOM, un negocio de venta de juegos piratas en Viña del Mar. Lo que buscaba era combinar en un único copiador:

Copiar juegos en formato XEX.
Cargador turbo, de esos que tienen una mayor tasa de transferencia (sonido más agudo) y menor tiempo de carga.
Retomar cargas en el punto que fallaron ("rebobine X vueltas").
Usar casseteras normales (sin sistema Injector).
Copiar juegos que requerían pausas para inicialización ("pitos lentos").

Este desarrollo tomó algunas semanas y la paga recibida fue la cassetera XC11 utilizada para el desarrollo y pruebas, y acceso libre a los juegos y demás software existente en el local. Después que desapareció SYFCOM de Viña, le entregué una copia a otro local similar: VCC (Video Compu Club), a cambio de una interface 850 con su módem para teléfono de gancho, un modem XM310, y obviamente acceso libre a los juegos que pasaran por el local.

S.I.T.R.E. quiere decir "Sistema Inteligente Turbo con Recuperación de Errores", pero en su fase inicial se llamó C.A.T.C.I. o "Cargador Automático Turbo Cassette Inteligente". Era muy feo el nombre original, y lo cambié por otro peor!!!

El desarrollo de SITRE lo realicé en mi 800XL estándar, sin memoria expandida, por lo que la primera versión sólo permitía copiar juegos de unos 24K. Con eso pude hacer todas las pruebas necesarias para poner las pausas de los pitos lentos y ajustar la velocidad máxima de grabación que permitiera hacer cargas sin fallos, y cuando forzaba los errores (por ejemplo presionando suavemente la tecla de pausa en la cassetera), podía retomar la carga retrocediendo la cinta un par de vueltas. Para ajustar los parámetros de grabación, era necesario modificar el S.O. en la ROM del Atari... ¡¿En la ROM?!

La arquitectura de los Atari XL/XE tiene un registro en memoria denominado PORTB, mediante el cual cambiando algunos bits se pueden activar o desactivar algunas ROM y RAM del sistema, haciendo que se pueda acceder a algunos de ellos mediante direcciones de memoria preestablecidas. De esta forma se puede activar y desactivar el lenguaje BASIC, la ROM del S.O., el Self Test, y los distintos bancos de memoria extendida.

Por lo tanto, para modificar el S.O. hay que copiarlo desde la ROM hacia la RAM accesible en el mismo rango de memoria, y luego se retocan los parámetros o rutinas necesarias.

Una vez que el copiador estuvo estabilizado, el siguiente paso fue permitir el uso de bancos de memoria extendida que poseen los 130XE, con lo cual se podían obtener los 64K adicionales, usando el mismo registro PORTB. Después de las pruebas correspondientes, el programa resultante en esta segunda versión fue el que le entregué a SYFCOM.

Todas las rutinas de carga de SITRE estaban programadas en Assembler 6502, ya que es lo requerido para cargar juegos desde cassette (sin BASIC, es decir, con la tecla OPTION presionada además de la tecla START). Sin embargo, el grabador (copiador) estaba escrito en BASIC, ya que ahí es bastante simple controlar el flujo del programa, efectuar la interacción con el usuario, y acceder a DOS para la manipulación de los XEX.

Sin embargo, muchas de las actividades necesarias habrían sido lentas y requerido bastante código en BASIC (ocupando además la escasa memoria disponible), por lo que varias de las acciones fueron programadas en Assembler en modalidad de código relocalizable, y accediéndolas mediante la funcion USR de AtariBASIC. Entre esas rutinas estaban la copia de la ROM hacia la RAM, la lectura del XEX hacia los bancos de memoria y la grabación del XEX en los bloques de cinta, usando los parámetros precalculados como los IRG para pitos lentos.

Inicié este post con la intención de hacer en SITRE lo mismo que dogdark está haciendo con CAIN en otro hilo del foro, es decir, lograr copiar a cassette juegos que pesan más de 64K, usando ampliaciones de memoria compatibles con 130XE y RAMBO en 800XL.

Para evaluar el cambio, es necesario tomar en cuenta el diseño de SITRE. Éste se basó en las siguienes definiciones:

Utilizar los 4 bancos de 16K de memoria extendida, totalizando 64K máximo para un XEX (en 1989 no vi ningún juego en formato XEX que llegara a los 60K).
Los bloques en cinta serían de 256 bytes de datos (más el overhead de control). Por lo tanto, el máximo de bloques en cinta sería 256.
El análisis del juego en busca de pitos lentos generaba una tabla de 256 bytes, uno por cada gap (IRG) a grabar en cinta. Así se ponen pausas sólo donde se necesitan.

Dado lo anterior, se observa que todos los contadores necesarios son de 8 bits (1 byte), y pueden ser utilizados sin problema en los registros X e Y de la CPU para acceder la memoria (buffers y tablas) en forma indexada.

A primera vista parecía muy simple hacer el cambio, pero observando estas definiciones de diseño, me encuentro con bastante trabajo, principalmente porque los contadores ya no serían de 1 byte, sino que de 2, ya que se requiere utilizar 10 bits para manejar hasta 1024 bloques de 256 bytes (256K). Como se puede apreciar, el impacto es grande... los registros X e Y de la CPU no serán capaces de acceder a tablas completas en forma directa (las tablas ya están a su máxima capacidad y habría que hacerlas crecer) y la manipulación de contadores también requieren al menos el doble de instrucciones en ASM. ¡Y eso está en todos lados!

Han pasado 26 años, y lo que he escrito aquí es el resultado de la búsqueda y revisión de los códigos fuentes de cada componente entre mis viejos diskettes o sus respaldos que alguna vez pasé a PC usando SIO2PC o 1050-2-PC. Aún no los encuentro todos, pero he avazado bastante. Al menos ya tengo la última versión 2 estable de SITRE en BASIC y gran parte de las rutinas en Assembler (MAC/65) para la carga desde cinta (empotradas en el copiador en forma de strings). Los códigos fuentes que no pille, deberé generarlos a mano con algún desensamblador de 6502, pero habiendo perdido los comentarios y etiquetas relevantes para recordar y entender lo que se hace... nada tan grave después de todo.

Eso es todo por ahora... A ver si esto va dejando contentos a AsCrNet y Suppawer

ACTUALIZACIÓN: Acceso directo al los listados de SITRE 2.01 (original 130XE) y SITRE 3.02 (modificado para 256K).

Publicado: **Sab Feb 21, 2015 2:33 pm**

Que buena!! Me gustó que hayas partido con la historia de SITRE, es uno de los cargadores famosos de esa época. Creo que fue el segundo cargador de ese tipo que vi, y eso de poner un nombre en base a una sigla después lo copié en CAIN

Ahora me dieron ganas de copiarte la idea de este post también, para que quede documentada la historia antes de que se nos olvide, como le pasa a Parche Negro

Sobre la carga de más de 64K, hay una parte que aun no sé cual será la mejor forma de resolverlo, y es el contador de cada bloque en la grabación final. Habrá un método mejor que desperdiciar todo un byte sólo para los casos en que se pase de los 64k? Convendrá aumentar el tamaño del bloque?

Saludos y quedamos atentos!

Publicado: **Sab Feb 21, 2015 4:49 pm**

Gran historia!
vitoco, en aquella época (con tus conocimientos y SITRE) ¿no te salía más rentable haber incursionado con un "negocio" propio de venta de juegos en cassettes?

¿Tuviste que ver también con este otro cargador?:
Imagen

(Seguiré muy atento a este tema

)

Publicado: **Sab Feb 21, 2015 5:42 pm**

Suppawer escribió:Gran historia!
vitoco, en aquella época (con tus conocimientos y SITRE) ¿no te salía más rentable haber incursionado con un "negocio" propio de venta de juegos en cassettes?

¿Tuviste que ver también con este otro cargador?:

(Seguiré muy atento a este tema )

Según lo que publica el mismo Vitoco, sí.

Después que desapareció SYFCOM de Viña, le entregué una copia a otro local similar: VCC (Video Compu Club), a cambio de una interface 850 con su módem para teléfono de gancho, un modem XM310, y obviamente acceso libre a los juegos que pasaran por el local.

Publicado: **Sab Feb 21, 2015 6:03 pm**

Suppawer escribió:vitoco, en aquella época ¿no te salía más rentable incursionar con un "negocio" propio de venta de juegos en cassettes?

Intenté incursionar en ese negocio, pero sólo en diskettes... entonces no tenía cassetera, ni tampoco disketera modificada para copiar juegos protegidos. Así que preferí dedicarme a desproteger juegos... y me entretenía más en mi ratos libres. Estaba recién comenzando en la universidad, así que no tenía tiempo para dedicarle al "negocio". Un verano puse un aviso clasificado en El Mercurio de Valparaíso... no vendí ningún juego, pero me contactaron Eagle Soft (de Concepción), John Drake (de Santiago) y Sunny Soft (de Viña)... Fue divertido, los de Conce estaban veraneando en Viña y se estaban cambiando a Atari ST, así que me hice de una buena cantidad de juegos en diskette. Y a pocas cuadras de ellos estaban veraneando también John Drake y Fernand Morgan... ellos cambiaban los créditos de los juegos, por lo que tenían la base de un algoritmo para buscar los textos. Yo lo mejoré y nació el BUSCADOR, pero eso es otra historia.

Suppawer escribió:¿Tuviste que ver también con este otro cargador?:

Esa pareciera ser alguna variación de los NHP de Parche Negro.

Los SITRE tienen este aspecto:

Imagen

La versión no dedicada dice "CARGANDO" en lugar del nombre del local.

fcatrin escribió:Que buena!! Me gustó que hayas partido con la historia de SITRE, es uno de los cargadores famosos de esa época. Creo que fue el segundo cargador de ese tipo que vi, y eso de poner un nombre en base a una sigla después lo copié en CAIN

No sabía que fuera tan "famoso" mi cargador. No tengo idea de cuántos juegos se habrán vendido que estuvieran grabados con SITRE, ni cuáles habrán funcionado OK en este cargador y no en otro.

fcatrin escribió:Ahora me dieron ganas de copiarte la idea de este post también, para que quede documentada la historia antes de que se nos olvide, como le pasa a Parche Negro

Sería bastante bueno que lo hicieras. Documentarás un poco la retro-historia que nos entretiene.

Hace un tiempo había intentado escribir al respecto de SITRE, y los amigos de atariware me alentaron a hacerlo, pero lo quería publicar en mi propia página. Cuando encontré un disco que tenía las versiones maestras que le pasé a SYFCOM y VCC, comencé a revisar el código, pero me faltaba el código fuente de la parte relevante: el cargador. Igual algo avancé, pero lo dejé botado por falta de tiempo.

Con lo de dogdark sobre CAIN me animó a retomar, y después de buscar en otros diskettes, encontré fuentes hace pocos días, pero sin estar seguro de que se trate de la última versión. Afortunadamente casi todos tienen una fecha puesta en comentarios, por lo que descarté versiones viejas. También encontré el copiador en versión estable sin protección ni dedicado a SYFCOM ni a VCC. Estuve comparando los más recientes de esos fuentes con lo que está ensamblado y empotrado en el copiador, y aún así no calzaron, así que simplemete actualicé el más reciente a lo que desensamblé. Ese será mi punto de partida para trabajar en una versión que pueda copiar más de 64K.

fcatrin escribió:Sobre la carga de más de 64K, hay una parte que aun no sé cual será la mejor forma de resolverlo, y es el contador de cada bloque en la grabación final. Habrá un método mejor que desperdiciar todo un byte sólo para los casos en que se pase de los 64k? Convendrá aumentar el tamaño del bloque?

Recuerdo haber leido que CAIN tiene bloques de 221 bytes (no sé si eso incluye bytes de control), con lo del rescate de Fantastic Soccer para NTSC desde un WAV vi que NHP usa 253 para datos. En SITRE yo usé 256 para datos. No estoy seguro que sea bueno crecer más. Si duplico a 512 bytes para mantener el máximo en 256 bloques, se complejiza harto la manipulación de la data, se arriesga más a chocar con el XEX que se está cargando, y tampoco se podría pasar de 128K. Mi idea es llegar a los 192K que permiten los bancos de un XL con 256K en RAM. Probablemente no sea tan mala idea crecer un byte más en el bloque, pero se me ocurre que sería posible quedarse sólo con el byte menos significativo y comparar ese con el que lleva el cargador, pues en la frontera del 255 y el 0 hay pocas posibilidades que estés 200 vueltas de cinta corrido. Voy a tomar esta estrategia, y creo que el complemento a 2 será de mucha ayuda.

Publicado: **Sab Feb 21, 2015 9:50 pm**

interesante la historia de como fue creado el copiador sitre, en su estructura y en la idea de los negocios por tener algo propio para vender el juego. Ahora con el tiempo que se necesita para realizar estas modificaciones, estaría muy bueno poder tener un nuevo copiador a las librerías que coleccionamos, gracias por la info vitoco me pareció muy interesante la historia y por compartirla con nosotros.

Publicado: **Sab Feb 21, 2015 9:59 pm**

Buenas anecdotas vitoco... Quedo atento al avance...

Publicado: **Dom Feb 22, 2015 2:14 am**

Seguí escarbando en mis diskettes en busca de los fuentes en Assembler. Ya había actualizado unas del cargador para reflejar los binarios que se graban a cinta, pero me faltaban algunas del copiador, en particular la que grababa a cinta los bloques del XEX, ¡y la encontré! Tiene hasta los comentarios

Viendo las variables que controlo, me doy cuenta que nunca se pasa como parámetro el número de bytes a copiar a las rutinas USR, por lo que no estaría en la situación del error 3 que afectó a la modificación de CAIN por tener un valor mayor que 64K. Por el contrario, la rutina de grabación no maneja los bancos de memoria, sino que en BASIC se selecciona cada banco y se itera con la llamada a la rutina que lo graba. Los parámetros corresponden a números de bloques y el número de bytes del último bloque de ese tramo. También van las tablas de pitos lentos completas, pero que fácilmente puedo restringir al segmento asociado a ese banco. Excelente, podré manejar tablas de más de 256 bytes, pero en segmentos de a 64.

Lo que sí estoy notando es que el copiador está muy ajustado en el uso de la memoria. Cabe justo entre el DOS y el área de memoria de acceso a los bancos, lo que me complicará un poco agregarle algunos chiches. Estoy pensando en mover algunas cosas a la memoria que está entre los bancos y la pantalla. Ahí hay unos 6K totalmente disponibles para buffers, el loader y demases. Voy a ver la mejor forma de hacerlo.

Volviendo a la historia de SITRE, comenté que primero hice una versión en mi 800XL estándar. Esa era la versión 1.01 de SITRE, con fecha de cierre en marzo de 1989, y que podía copiar hasta 24K aproximadamente. Después lo modifiqué para trabajar con bancos del 130XE, y a esa versión la denominé 2.01, y tiene fecha de abril del mismo año.

Después de entregar esa última versión para copiar hasta 64K, me quedé con las ganas de poder hacerlo en el 800XL... lo que intenté fue modificar el copiador para que grabara por etapas, es decir, cargaba un trozo del XEX, grababa en cinta el cargador seguido del trozo de XEX, luego detenía la cinta y cargaba otro trozo en memoria, para luego encender la cinta otra vez y continuar la grabación. Hasta donde recuerdo, no tuve problemas con la grabación, pero durante la carga, al llegar al corte, siempre fallaba la carga... no sé qué habré hecho mal o si me faltó investigar algo.

Comento esto porque buscando los fuentes perdidos, me encontré con unas versiones del copiador que dicen 1.11 con fecha de junio del mismo año 1989, e imagino que se trata de eso. No lo voy a mirar por ahora, pero no deja de ser interesante

Lo que sí me pareció curioso es que en el mismo disco pillé un código en Assembler con fecha de octubre de 1989 que dice "RESCATA STAC SOFT LOGIC".

Esa rutina USR controla el motor de la cassetera, así que me imagino que debe ser algo que hice para recuperar algunos XEX novedosos que sólo llegaban en cinta a Viña. Mucho más no recuerdo, pero es algo que hacía con cierta frecuencia... En un caso en particular, eso me trajo indirectamente problemas con Rod Rubber de LaserGame en Santiago, lo cual es otra historia.

Publicado: **Dom Feb 22, 2015 6:28 am**

vitoco escribió:... En un caso en particular, eso me trajo indirectamente problemas con Rod Rubber de LaserGame en Santiago, lo cual es otra historia.

Suena a buena historia.

Publicado: **Dom Feb 22, 2015 11:30 am**

Ya he visto bastante código de SITRE, y puedo decir que hay muchas cosas ahora que habría hecho de otra forma. Igual me sorprendo de algunas optimizaciones y de la forma que resolví problemas.

Entre las cosas curiosas, vi que la lista de bloques con pitos lentos está en orden inverso, para ir de la mano con el contador que se almacenaba en cada bloque. Obvio, si el bloque cero es el último en grabarse. Eso explicaba tanta fórmula en el programa en BASIC. Pero por lo mismo, también me doy cuenta que n cada bloque hay un byte que indica el tamaño del bloque, siendo que es constante excepto en el bloque cero!!! Franco, ahí yo perdí un byte....

Hasta el momento, para hacer una versión de 256K, identifico los siguientes cambios:

Aumentar a 2 bytes el contador en las rutinas del cargador. Eso implica duplicar código para manipularlos, y el cargador crecerá en tamaño unos pocos bytes.
Aumentar en un byte el indicador del número de bloque que se está cargando, lo cual impacta en el tamaño de bloque. Alternativamente, puedo mantener ese dato en un byte y usar complemento a 2 para las condiciones. Otra alternativa más es reasignar el byte con el tamaño del bloque de datos, ya que es constante salvo al final de la carga.
Cambiar la forma en que se administran los bancos de memoria, usando la técnica que expliqué en el otro hilo. La idea es llegar a utilizar hasta 13 bancos de 16K (1 de memoria real y hasta 12 de memoria extendida, dependiendo del hardware reconocido).
Aumentar el tamaño de la tabla de pitos lentos. Actualmente tiene un byte por bloque indicando la duración de la pausa, aunque en la práctica se están grabando todas iguales. No me agrada cambiarla a 1 bit por bloque, porque quedaría bastante más compleja su manipulación. Mantener los bytes requiere usar más memoria: actualmente se usan 256 bytes para 4 bancos, y si quiero llegar a 13 bancos, necesito 576 bytes adicionales. El problema es que no queda memoria disponible para strings en BASIC, y deberé llevarla a memoria superior. Ahí también pondré los buffers.
Modificar la rutina para identificar los pitos lentos. Esa está escrita en BASIC, pero usa una rutina USR para leer bytes directamente de los 4 bancos del 130XE como si se tratara de memoria contínua. Con el cambio en la manipulación de bancos, eso deberá ser reescrito completamente. Ojo que además me encontraré con el problema del error 3 al tratar de direccionar más de 64K.
Dependiendo de lo anterior, habrá que modificar la rutina de grabación de bloques del XEX a cinta para incluir los distintos cambios de esquema en forma consistente.
Esto ya es más discutible: ¿mejorar SITRE en su operación o mantenerlo tal cual? Por ejemplo, cuando falla un bloque, aparece un mensaje y el efecto rainbow, pero como la idea es no alterar lo que el XEX haya hecho antes, como apagar la pantalla o poner una presentación con características especiales, sólo se intenta un cambio simple para mostrar el mensaje, y cuando eso no se cambia sólo queda el efecto de colores como indicación. ¿Hago un esfuerzo extra para cambiar la pantalla completa y después restaurarla cuando se retome la carga? Por ahora opto por mantenerlo tal cual, porque son muchas las cosas a controlar, incluso DLIs.

Veremos por donde comienzo, a ver si saltan más conejos.

Nes_milio escribió:
vitoco escribió:... En un caso en particular, eso me trajo indirectamente problemas con Rod Rubber de LaserGame en Santiago, lo cual es otra historia.
Suena a buena historia.

Ni tanto...

Publicado: **Dom Feb 22, 2015 12:47 pm**

Nes_milio escribió:
vitoco escribió:... En un caso en particular, eso me trajo indirectamente problemas con Rod Rubber de LaserGame en Santiago, lo cual es otra historia.
Suena a buena historia.

Y no me extraña... al parecer con varios tuvo problemas...

Publicado: **Dom Feb 22, 2015 7:42 pm**

vitoco escribió:
fcatrin escribió:Que buena!! Me gustó que hayas partido con la historia de SITRE, es uno de los cargadores famosos de esa época. Creo que fue el segundo cargador de ese tipo que vi, y eso de poner un nombre en base a una sigla después lo copié en CAIN
No sabía que fuera tan "famoso" mi cargador. No tengo idea de cuántos juegos se habrán vendido que estuvieran grabados con SITRE, ni cuáles habrán funcionado OK en este cargador y no en otro.

Me llegaron varias copias de juegos con SITRE. Acá en la región siempre se propaga desde Valpo al Interior, así que todo lo que se hacía en Valpo o Viña llegaba a Quilpué y Villa Alemana

vitoco escribió:
fcatrin escribió:Ahora me dieron ganas de copiarte la idea de este post también, para que quede documentada la historia antes de que se nos olvide, como le pasa a Parche Negro
Sería bastante bueno que lo hicieras. Documentarás un poco la retro-historia que nos entretiene.

Lo haré entonces! Tengo hasta los cuadernos que usaba en esos tiempos.

Publicado: **Dom Feb 22, 2015 7:55 pm**

fcatrin escribió:
vitoco escribió:
fcatrin escribió:Ahora me dieron ganas de copiarte la idea de este post también, para que quede documentada la historia antes de que se nos olvide, como le pasa a Parche Negro
Sería bastante bueno que lo hicieras. Documentarás un poco la retro-historia que nos entretiene.
Lo haré entonces! Tengo hasta los cuadernos que usaba en esos tiempos.

Ja, ja, ja... parte de lo que he recapitulado de SITRE lo he sacado de mi cuaderno naranja. Intenté sacarle fotos a algunas páginas para ponerlas acá y no se cacha nada, pues todo lo escribía con lápiz grafito, y ahora además las hojas están amarillentas (Retr0bright no aplica en ellas). Intentaré escanear en alto contraste o con filtros.

También sería bueno convencer a Parche para que haga su parte para reconstruir y preservar la historia...

Publicado: **Mié Feb 25, 2015 2:40 am**

Ufff... Costó, pero creo que lo logré. Pude grabar el Goonies-130XE de 72.670 bytes en un .CAS usando SITRE modificado en el emulador Atari800-a8cas con 128K de RAM y posteriormente lo cargué en Altirra con 320K. Va el adjunto para que lo prueben. Si alguien lo puede pasar a WAV y cargar en un Atari 130XE real o en 800XL con 256K, sería genial que compartiera la experiencia. Pero le advierto que son 18 minutos de carga!!!

Grabando:
Imagen

Cargando:

Después del pito lento, se instala la presentación propia:
Imagen

Forzando un error moviendo el control del .CAS un poco más adelante de donde iba:
Imagen

Carga finalizada:
Imagen

¿Y cómo logré esto? Vamos a lo técnico...

Hasta ahora no me había referido a los internals de SITRE, pero llegó el momento, y voy a comenzar con el cargador (loader), pues es lo primero que modifiqué.

El cargador de SITRE consta de 4 partes que se graban a cinta antes que el XEX:

Boot record: Es un registro de formato estándar que no tiene código a ejecutar, sino que sólo se usa para cargar en memoria los vectores de ejecución de SITRE. Si alguien lee la cinta usando un copiador en BASIC, lo que verá es sólo un mensaje de relleno indicando que se trata de SITRE. Pude haber puesto ahí también el nombre del juego grabado, pero ya no fue.
Registro EOF (falso): En cassette se requiere un bloque extra al final de la grabación. Normalmente ese bloque está vacío, pero en el caso de SITRE va la rutina de inicialización, la cual queda en el buffer de cassette estándar en memoria. Esta rutina carga el 3er bloque y le pasa el control.
Primera etapa de carga turbo: Este bloque carga en página 6 y ahí está contenida la pantalla de característica de SITRE. Si el XEX que se cargue tiene su propia pantalla de presentación (usualmente son los juegos que requieren pitos lentos), la de SITRE será reemplazada, incluso si carga en la misma página 6. Este bloque tiene además la rutina que carga el 4to bloque y principal de SITRE.
Segunda etapa turbo: Este bloque entra en página 7 y contiene el cargador de SITRE. Aquí está el código para la carga del XEX, incluyendo las rutinas de carga de bloques, de su validación y reintentos. También contiene la pantalla de reintentos en caso de error y el mensaje "quedan XXX bloques" que se muestra además en la pantalla cargada en la primera etapa; el mensaje va aquí por seguridad, pues si un XEX carga código en página 6, SITRE podría corromper código válido al decrementar el contador.

A continuación van los bloques de XEX, los cuales tienen la siguiente estructura:

2 bytes para ajuste de velocidad (BAUD). Son constantes y ambos tienen el valor $55 (en binario son unos y ceros alternados).
1 byte para indicar el número del bloque. En SITRE, los números van en orden decreciente, siendo el bloque 0 el último en cargar. De esta forma se permitía cargar hasta 256 bloques.
1 byte para indicar la cantidad de bytes en el bloque. Esto fue pensado para permitir la carga de bloques parciales y facilitar la funcionalidad de pitos lentos, pero finalmente no fue necesario, excepto para el último bloque que sí puede traer pocos bytes. A diferencia de otros cargadores que he visto, no se requiere de bytes de control adicionales para indicar el término del XEX.
256 bytes de datos. Los bytes que no se usan a la cola (indicado por el byte anterior) son considerados basura.
1 byte de checksum, puesto por la rutina SIO del sistema al momento de grabar y controlado también por SIO al momento de leer el bloque. Si no calzan, se activa la pantalla con efecto rainbow solicitando rebobinar para reintentar.

Finalmente, en la cinta se graba el registro EOF real, a velocidad normal (no turbo) y que fue simulado en el segundo bloque al grabar. Este bloque no es leído por SITRE, pues la cinta es detenida justo antes para pasarle el control al XEX.

Dado todo lo anterior, se puede observar que hay una restricción en el tamaño máximo del XEX: 256 bloques por 256 bytes permiten 65.536 bytes (64K). Por lo tanto, para poder cargar XEX de mayor tamaño, se requerió modificar el loader. Pensé en incorporar 1 byte adicional para el contador de bloques en la data del XEX o en reemplazar la funcionalidad del byte del tamaño del bloque (como sólo es relevante en el último bloque, se podíra almacenar por separado junto al loader), pero como quería tocar lo menos posible el código original, me aproveché de las características del álgebra binaria en complemento a 2 y no fue necesario modificar los bloques del XEX. Simplemente comparé un registro de 8 bits con el LSB de uno de 16 bits. Este cambio agregó unos pocos bytes al 4to segmento, pero eso impactó al 3ro, pues se corrieron algunos vectores, lo que de paso afectó al 2do. El 1ro no se salvó porque ahí iba la fecha de la versión de SITRE que tenía el bug Y2K, así que la cambié por la fecha de hoy.

Pero para poder llevar el cargador a cinta, fue necesario modificar el copiador. Mi intensión era modificar lo menos posible y mantener la concepción origina de SITRE, pero creo que debo haber cambiado como un tercio del programa BASIC. Si bien no modifiqué la estructura y conserve el orden, los nombres de las variables y hasta los números de línea, varias cosas debieron ser cambiadas radicalmente.

Detalles técnicos del por qué en el spoiler...

Spoiler: MOSTRAR

El programa original de SITRE en BASIC incluía todas las rutinas en lenguaje de máquina como asignaciones a cadenas empotradas en el código, incluyendo las 4 etapas del cargador, con la consecuencia que cuando el programa iniciaba, todas ellas quedaban duplicadas en memoria (en el área de código y en el área de valores).

Así, la cantidad de memoria total que utilizaba SITRE era muy cercano al límite de 8K. Para poder grabar más de 64K (256 bloques), era necesario hacer crecer algunos buffers, en particular la tabla para marcar los pitos lentos (64 bytes por cada banco extra), y no era posible crecer sin chocar con la zona para el acceso a los bancos de memoria.

Por lo tanto, el primer paso fue cambiar la forma en que se accedían a las rutinas USR: en lugar de asignarlas a variables de tipo cadena, se cambiaron a variables numéricas, y se les asignó como valor la dirección de la cadena directamente en el área de instrucciones. Es decir:

Código: Seleccionar todo

10 DIM RUTINA$(47)
20 RUTINA$="CARACTERES ATASCII REPRESENTANDO CODIGO BINARIO"
30 U=USR(ADR(RUTINA$),1,2,3)

se cambió por:

Código: Seleccionar todo

10 RUTINA=ADR("CARACTERES ATASCII REPRESENTANDO CODIGO BINARIO")
30 U=USR(RUTINA,1,2,3)

El segundo paso fue mover los buffers que estaban en otras variables de tipo cadena hacia el área de memoria disponible sobre la zona de acceso a los bancos. Ahí hay sobre 6K disponibles para todos ellos, y a la tabla de pitos lentos le asigné tranquilamente 2K.

Ya con memoria suficiente para trabajar en las cosas nuevas, introduje la nueva forma de operar con los bancos. Originalmente utilizaba el mecanismo de usar un valor base para asignar al registro PORTB y a ese sumarle el número del banco a seleccionar, pero ahora utiliza el esquema de valores predefinidos que propuse en otro hilo, a recordar en el siguiente spoiler.

Spoiler: MOSTRAR

El acceso a la memoria extendida del 130XE y del 800XL modificado se realiza a través de bancos de memoria de 16K cada uno, accesibles a través de una zona fija de memoria ($4000-$7FFF) que es reemplazada por el banco. Para activar un banco específico, se debe modificar algunos bits en el registro de hardware denominado PORTB (dirección de memoria 54017). La combinación de bits requerida para cada banco es la siguiente:

Código: Seleccionar todo

       | POKE  | Banco real | D=0     V=0 E=0         B=0 R=1
 Banco | 54017 | 130XE 256K |  7   6   5   4   3   2   1   0 
-------|-------|------------|---------------------------------
   0   |  177  |  RAM   RAM |  1   0   1   1   0   0   0   1 
   1   |  161  |   0     4  |  1   0   1   0   0   0   0   1 
   2   |  165  |   1     5  |  1   0   1   0   0   1   0   1 
   3   |  169  |   2     6  |  1   0   1   0   1   0   0   1 
   4   |  173  |   3     7  |  1   0   1   0   1   1   0   1 
   5   |  193  |         8  |  1   1   0   0   0   0   0   1 
   6   |  197  |         9  |  1   1   0   0   0   1   0   1 
   7   |  201  |        10  |  1   1   0   0   1   0   0   1 
   8   |  205  |        11  |  1   1   0   0   1   1   0   1 
   9   |  225  |        12  |  1   1   1   0   0   0   0   1 
  10   |  229  |        13  |  1   1   1   0   0   1   0   1 
  11   |  233  |        14  |  1   1   1   0   1   0   0   1 
  12   |  237  |        15  |  1   1   1   0   1   1   0   1 
-------|-------|------------|---------------------------------
  13   |  129  |         0  |  1   0   0   0   0   0   0   1 
  14   |  133  |         1  |  1   0   0   0   0   1   0   1 
  15   |  137  |         2  |  1   0   0   0   1   0   0   1 
  16   |  141  |         3  |  1   0   0   0   1   1   0   1

En la tabla puse los bancos ordenados de forma que sean compatibles un 130XE con un 800XL con el mod de Claus Bushholz o RAMBO (XL o 320K), en que el banco 0 representa la memoria real, los bancos 1 al 4 a los bancos del 130XE, los 5 al 12 al 800XL con mod, y del 13 al 16 los de RAMBO-320K. Esto se puede extender a 16 valores más para un mod de 512K, en que se repiten los valores anteriores, pero con el bit 7 en cero (se resta 128 a los valores de los bancos 1 al 16 para habilitar del 17 al 32).

Para acceder a cada banco en forma simple, basta asignar un arreglo con los valores establecidos, y usar esos valores para modificar PORTB. En BASIC, sería de la siguiente forma:

Código: Seleccionar todo

1 M=16:DIM B(M+1):FOR I=0 TO M:READ X:B(I)=X:NEXT I
2 DATA 177,161,165,169,173,193,197,201,205,225,229,233,237,129,133,137,141

La variable M indica cuántos bancos se podrían utilizar. El arreglo B tiene los M+1 valores posibles, partiendo de 0 para memoria real hasta el máximo banco M.

Para determinar en forma dinámica cuánta memoria extra dispone el programa, es decir, cuantos bancos están disponibles dependiendo del tipo de computador o modificación, se puede usar el siguiente código que ajusta M al máximo posible:

Código: Seleccionar todo

3 FOR I=M TO 1 STEP -1:POKE 54017,B(I):POKE 16384,B(I):NEXT I
4 FOR I=1 TO M:POKE 54017,B(I):IF PEEK(16384)=B(I) THEN NEXT I
5 IF I<=M THEN M=I-1:POP
6 PRINT M

La línea 3 marca cada banco con un valor individual, y las líneas 4 y 5 determinan cuál es el mayor banco utilizable.

Como consecuencia del cambio para manipular bancos, tuve que cambiar el proceso de carga del XEX, el de análisis para descubrir dónde aplicar pitos lentos y la rutina de grabación de bloques en cinta. Sin embargo, me impresionó lo simple que quedó con el arreglo de valores predefinidos para PORTB. Pero debo hacer notar algo relevante: los valores del arreglo habilitan los respectivos bancos, pero suponen que el bit 1 del registro está encendido, es decir, que está presente la ROM del S.O., lo cual no es siempre cierto en SITRE; cuando se graba en modalidad turbo, se están usando las rutinas modificadas de SIO, por lo que la ROM debe estar desactivada, y en ese caso los bancos se activan con:

Código: Seleccionar todo

POKE 54017,B(I)-1

Como consecuencia del nuevo tamaño de la tabla de pitos lentos, decidí que la rutina utilizara sólo el rango asignado a los bloques de la página que se está grabando, por lo que las marcas ya no se están almacenando en orden invertido como comenté en un post anterior. Mientras acomodaba el código para trabajar con la porción correspondiente, me di cuenta que sí se estaba considerando la duración de las pausas en forma individual, es decir, no se estaba ignorando ese dato como también lo aseguré en ese post.

En la pasada se fueron a la basura:

Una rutina USR para acceder a los bancos de memoria como si se tratara de memoria lineal y simular un PEEK sobre ella, pues estaba restringida a 64K, y no tenía sentido cambiarla porque me toparía con el ERROR 3 si intentaba pasar en un parámetro un valor mayor a 65535. Como debía separar el valor de la dirección en 2 valores de 16 bits, en realidad no costaba nada hacer el cambio de banco y leer el valor deseado en la misma subrutina. Como la rutina USR también permitía hacer POKE, la nueva rutina se clonó para habilitar esa funcionalidad.
Una rutina USR que limpiaba los 4 bancos de memoria del 130XE antes de cargar el XEX. Como ahora podría haber más de 4 bancos, y a cinta se van los datos que se carguen del XEX, no era necesario inicializar la memoria, salvo para el último bloque, pero ya dije que el cargador ignorará eso. De todos modos es una mejora pendiente.
La antigua rutina que verificaba que se trate de un 130XE. Fue reemplazado por una optimización del esquema para detectar los bancos disponibles, y ahora en vez de bloquearse, indica cuántos bancos hay disponibles para copiar, que puede ser sólo 1 en el caso de un 800XL estándar.

Lo que va quedando pendiente:

Rutina en Assembler para inicializar los buffers. Actualmente la tabla de pitos lentos no se limpia si se copian varios XEX en la misma sesión y las marcas se van acumulando. Nada grave por cierto, pero usar un ciclo FOR-NEXT para 2000 iteraciones introduce una latencia innecesaria.
Hacer algún cambio para que el último bloque no contenga basura, lo que se produciría cuando se graba un XEX más pequeño que otro grabado anteriormente en la misma sesión. Para ello hay alternativas sin tener que limpiar todos los bancos antes de cargar un XEX, por ejemplo borrar sólo los bytes siguientes al último byte cargado del XEX hasta completar la página de 256 bytes, o bien modificar la rutina de grabación para que cuando se vaya a grabar el bloque con identificador cero (el último), se rellenen los bytes mayores al largo de registro.
Restringir el número máximo de bloques a grabar en cinta a 999 o cambiar el contador a 4 dígitos. 999 bloques son 255.744 bytes, para los cuales se necesitan algo más de 15 bancos. Lo más simple es restringir el M a 15, aunque en el MOD de Bushholz sólo hay 12+1=13. Con 15 bancos, el contador llegaría a 960, y serían 59 minutos de carga... pero no he visto un XEX de 245K, eso es casi un diskette de densidad ampliada grabado por los 2 lados!!!
Permitir la lectura de XEX desde unidades de disco distintos de "D1:". Cuando desarrollé SITRE, pocos tenían más de una disketera.

Espero tener un poco de tiempo para estos ajustes...

Publicado: **Mié Feb 25, 2015 7:53 am**

muy bueno pues vitoco, si quieres probar un juego larrgooooo para ver el banco de memoria disponible completo realizalo con el comando para 256k ahí si que se demora. sería una buena prueba, claro que este viene en disco de doble densidad.

Publicado: **Mié Feb 25, 2015 1:43 pm**

No se por que me meto aqui, si no entiendo ni una "Rechascapiscas que me lleve el del moño"...

haber: esto puede servir para que los demas tambien entiendan;

1.- yo en tiempos de ataños juege el Goonies en cassette, y recuerdo perfectamente que en cada pantalla tenia que cargar por independiente, si perdia cargaba denuevo la primera pantalla, asi lo termine en un 130XE

2.-entonce ahora se puede cargar completamente de un paraguazo aprovechando la memoria completa del 130XE???

Publicado: **Mié Feb 25, 2015 3:39 pm**

NicolasBeg escribió:No se por que me meto aqui, si no entiendo ni una "Rechascapiscas que me lleve el del moño"...

haber: esto puede servir para que los demas tambien entiendan;

1.- yo en tiempos de ataños juege el Goonies en cassette, y recuerdo perfectamente que en cada pantalla tenia que cargar por independiente, si perdia cargaba denuevo la primera pantalla, asi lo termine en un 130XE

2.-entonce ahora se puede cargar completamente de un paraguazo aprovechando la memoria completa del 130XE???

La idea es que todos aprendamos. A lo mejor no he sido muy claro o quizás demasiado técnico y tal vez sólo Franco y dogdark me sigan. Pero efectivamente el CAS publicado carga de cinta el juego The Goonies completamente en memoria extendida, y las etapas son rescatadas de ahí, como si se tratara de un RAMDISK. Pero esa no es una gracia de SITRE, sino que del XEX en sí... SITRE sólo permitió ponerlo en cinta (y obviamente cargarlo desde ahí).

dogdark escribió:muy bueno pues vitoco, si quieres probar un juego larrgooooo para ver el banco de memoria disponible completo realizalo con el comando para 256k ahí si que se demora. sería una buena prueba, claro que este viene en disco de doble densidad.

Si no me pones un enlace al XEX o ATR, me obligas a buscarlo en la red. El primero que encontré es el Commando original, pero es en formato cartucho ROM de 128K... next! Luego encontré un ATR con el Commando+256K en formato ATR, que si bien contiene un XEX, no está en formato DOS, así que tuve que extraer el XEX... pero me llamó la atención que está modificado respecto del original. Busqué otras alternativas y encontré 2 XEX más, uno para Atari con ampliación de 192K y otro para 320K. Este último es el mismo que el XEX extraído, en tanto que el para 192K se ve idéntico al ROM. Como todos los XEX eran similares en contenido y pesaban casi los mismos 128K, y además tenían los mismos créditos, opté por hacer la prueba con el que era más parecido al ROM. Sin embargo, noté que no pasaría la frontera de los 128K, sino que sólo usaría 506 bloques, por lo que cambié de opción y me pasé al que extraje del ATR, porque ocuparía más de 512 bloques.

Pero como lo necesitaba dentro de un ATR formateado con algún DOS para poder leerlo con SITRE en el emulador atari800-a8cas con ampliación 320K-RAMBO, tal como mencionaste, tuve que crear uno de doble densidad con MyDOS y poner ahí el XEX.

Esto me sirvió además para probar que SITRE funciona OK en otro DOS (sólo lo había usado en DOS 2.5). Un cambio que hice en SITRE y que no mencioné en mi post anterior es que valida que no se choque el programa BASIC con la ventana para el acceso a los bancos de memoria extendida, haciéndolo un poco más independiente del DOS o de las extensiones que éste tenga y que le quiten un poco de memoria a BASIC.

El resultado fue el siguiente: SITRE cargó en memoria los 131.588 bytes y realizó el análisis en busca de las pausas para pitos lentos y detectar posibles bloqueos durante la carga. Pasó OK la prueba y encontró varios bloques que requerían pitos lentos (aproximadamente cada 16K, es decir, pareciera ser que carga tramos de 16K directamente en cada banco). En total, se necesitaron 515 bloques en cinta y poco más de media hora de grabación:
Imagen

Inicié el CAS generado en Altirra con ampliación 320-RAMBO, y apareció SITRE:
Imagen

Este era el momento de hacer pruebas con el control de errores en la carga. Como se está utilizando un contador de 8 bits, el número máximo de bloque representado es el 255, por lo tanto existía la posibilidad que mi teroría de complemento a 2 fallara por comparar sólo los LSB (bytes de menor relevancia) en la frontera de los bloques múltiplos de 256, donde se incluye el 512. Así que apenas comenzó la carga, forcé una caída adelantando y retrocediendo repetidamente la cinta en el emulador. Pude comprobar que todo operó bien antes de 512, en los 512 y después de los 512:
Imagen

(antes)

(durante)

(después)

Mirando esas 3 pantallas, se puede apreciar algo que comenté en un post anterior: entre las pruebas del control de errores hubo un pito lento, y apareció la pantalla de presentación propia del XEX. Como esta rutina cambia el modo gráfico de 40 a 32 caracteres (20 a 16 caracteres en modo 1 y 2), y esa característica no es alterada por SITRE, se provocó el corrimiento de los mensajes. También se ve que el texto cambió de color por el mismo motivo.

La pantalla de carga propia es la siguiente. Aparentemente hay manejo de interrupciones en pantalla (DLI), porque se puede apreciar que el texto no respeta una matriz, y hay líneas que están corridas medio caracter hacia un costado, para mantener centrado el texto de cada línea en la pantalla:
Imagen

Alrededor de los 3 minutos, en otro pito lento, algo hace el loader internamente con lo que va cargado hasta el momento:
Imagen

Después de media hora, el mensaje de la pantalla cambió:
Imagen

Prersionando una tecla comienza el juego:
Imagen

Pantalla de presentación del juego (modificada respecto de la que muestra la ROM):
Imagen

Comienza la acción:
Imagen

No hay caso, para mí es inmanejable sin un joystick... No puedo probar que no esté corrupto intentando pasar niveles:
Imagen

Repetí la prueba, pero emulando un 130XE. Apareció un mensaje diciendo que no había suficiente memoria extendida:
Imagen

Pero no me quedé tranquilo, e hice la prueba con el XEX parq equipos con 192K. También funcionó en forma muy similar (hartos pitos lentos repartidos y un rutina de inicialización con los créditos similares). Pero la pantalla de presentación del juego es la misma del cartucho:
Imagen

"Commando"

Spoiler: MOSTRAR

No sé si sólo modificaron la imagen y la música de la presentación o si hay algo más, pero se me ocurre que no, ya que en ambos casos los créditos son de Fandal.

Van adjuntos ambos CAS... Porfa, si alguien puede probarlos en Cassette y Atari reales, que comente su experiencia aquí mismo.

Publicado: **Mié Feb 25, 2015 7:46 pm**

vitoco zorry, se me olvido colocar el link del xex, es que llegue a las 8 de la mañana de la pega, se me fué, el cas no lo puedo pasar a wav para probarlo en el atari real, podrías crear estos con el a8cas, te dejo el link del emulador para grabarlo en wav directamente, este emulador es el que uso yo para crea juegos en wav

a8cas

ahora deje convirtiendo el cas en wav a ver si funciona y lo probaré en el atari real y te cuento como saldrá todo. se demora porque tengo win 8 y tengo que emular el DOS para la conversión y el juego es larguiiiiisimo, un abrazo.

Publicado: **Mié Feb 25, 2015 8:19 pm**

El emulador atari800-a8cas puede grabar directamente en WAV, pero no lo hice porque es media hora!!! La primeros bloques estaban ocupando varios megas, así que lo cancelé y cambié a CAS, total los emuladores lo transforman automáticamente a WAV cuando no se usa el SIO patch. Así fue como hice mis pruebas.

Ojalá alguien pueda hacer la conversión a WAV y grabar en cinta para probar en Atari real.

Publicado: **Mié Feb 25, 2015 8:24 pm**

Primero, felicitaciones por las modificaciones a SITRE. Si no me equivoco, este sería el primer copiador con turbo y recuperación de errores con soporte de más de 64KB!

Segundo, había olvidado comentar esto:

vitoco escribió: Después de entregar esa última versión para copiar hasta 64K, me quedé con las ganas de poder hacerlo en el 800XL... lo que intenté fue modificar el copiador para que grabara por etapas, es decir, cargaba un trozo del XEX, grababa en cinta el cargador seguido del trozo de XEX, luego detenía la cinta y cargaba otro trozo en memoria, para luego encender la cinta otra vez y continuar la grabación. Hasta donde recuerdo, no tuve problemas con la grabación, pero durante la carga, al llegar al corte, siempre fallaba la carga... no sé qué habré hecho mal o si me faltó investigar algo.

Difícilmente iba a funcionar. Cuando se detiene el motor, la cinta sigue girando después de que se ha detenido la grabación, por lo que quedarás con un espacio sin grabar, con ruido. En el momento de la carga, cada vez que se encuentra en un IRG, se espera que aparezca el primer "1" de la secuencia 0x5555 para calcular la velocidad. Si hay un trozo no grabado, es muy probable que parte de ese ruido se interpretara como "1" haciendo fallar el cálculo.

Una alternativa sería que el cargador descartara "1"s falsos, o tuviera una especie de timeout, pero eso sería muy complejo. Otra alternativa, menos compleja pero más manual sería dejar un IRG muy largo al final, luego rebobinar la cinta y dejarla lista para grabar partiendo encima de ese IRG, pero siempre estaría el riesgo de tener un ruido por ahí.

Saludos

Retronia

[ATARI] Copiador SITRE para juegos en cassette

[ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette

Re: [ATARI] Copiador SITRE para juegos en cassette