[ATARI] Copiador SITRE para juegos en cassette

Software y Juegos para retro-computadores, bueeeno... casi puros juegos :-)
Avatar de Usuario
dogdark
Mensajes: 594
Registrado: Lun Mar 04, 2013 1:36 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por dogdark » Mié Feb 25, 2015 8:49 pm

aca les dejo el sitre en wav para el uso posterior. ahora lo probare en el atari real a ver como nos va, el juego por lo menos cargo bien en el emulador a8cas
Adjuntos
Sitre_comando256k.rar
comando256ksitrewav
(783.89 KiB) Descargado 187 veces

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Mié Feb 25, 2015 10:16 pm

fcatrin escribió: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!
Pero si es cuando más se necesita!!!! Sin un cargador que reintente, no es lo mismo tener que cargar todo otra vez si falla a los 5 minutos que a los 25...
fcatrin escribió: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í.
Sí, tienes razón en que esos fueron los síntomas. Fíjate que intenté lo de los gaps, tanto antes como después de la detención de la cinta, pero siempre quedaba un ruido que si bien no era un "tic", variaba el tono producto de la desaceleración y la aceleración de la cinta en el cabezal de grabación. Creo que lo último que propones sufrirá del mismo síntoma que describo. Ahora pienso otras combinaciones o mecanismos para ignorar esa situación en el medio de una carga, pero ya no sé si valga la pena intentarlo. Ya es más fácil acceder a equipos con más memoria o basta usar emuladores que superan cualquier mod físico para generar un WAV. Incluso podría reescribir el copiador SITRE como un simple script en lenguaje perl para pasar cualquier XEX directamente a CAS sin usar bibliotecas de audio ni emuladores, y los usuarios no se darían ni cuenta.
dogdark escribió:aca les dejo el sitre en wav para el uso posterior. ahora lo probare en el atari real a ver como nos va, el juego por lo menos cargo bien en el emulador a8cas
¡Gracias! Vi que el WAV quedó de 800MB, pero no sabía que se podía comprimir tanto. :shock:
Espero el resultado de tu prueba.

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Jue Feb 26, 2015 7:21 pm

vitoco escribió:Lo que va quedando pendiente:
  1. 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.
  2. 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.
  3. 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!!!
  4. Permitir la lectura de XEX desde unidades de disco distintos de "D1:". Cuando desarrollé SITRE, pocos tenían más de una disketera.
Hecho... Respectivamente:
  1. Escribí una pequeña rutina USR que inicializa un tramo de memoria al valor indicado (asume cero si se omite). Además, dejé la tabla de pausas de tamaño variable, dependiendo del número máximo de bancos disponibles, por lo que a la rutina de inicialización se le pasan esos datos.
  2. Utilicé la misma rutina de inicialización del punto anterior para completar el último bloque en caso que tenga menos de 256 bytes, reemplazando posible basura que haya quedado ahí. Así no es necesario inicializar todos los bancos.
  3. Decidí restringir el número de bancos a lo especificado por el mod de Buchholz, es decir, dividir los 256K en 4 bancos para memoria real (64K) y 12 bancos para memora extendida (192K), por lo que SITRE cuenta sólo con 13 bancos en total para cargar un XEX (208K). Así, el valor máximo del contador será 832. El motivo para no usar los 4 bancos extra del mod 320K-RAMBO es porque no es 100% estándar o compatible con RAMBO/XL, y en algunos casos habilitar por ejemplo al banco 16, en realidad se estaría poniendo la copia que modifiqué del S.O. en la ventana de bancos, y si meto ahí un trozo de XEX, simplemente me quedo sin S.O.... ¡¡¡Crash!!!
  4. Ahora se permite especificar la unidad desde donde se va a leer el archivo. Si se omite, asume "D:" (disco 1). Además, si no se indica un nombre del archivo, se lista el directorio de la unidad especificada.
A diferencia de mi proyecto de juego, en que todo el desarrollo está siendo realizado en PC (ensamblador MADS, tracker RMT, editor de fonts y emuladores para probar el XEX resultante), en el caso de SITRE he trabajado a la usanza antigua, aunque no con Atari físico ni diskettes reales, sino que emuladores y ATRs. Esto me ha significado trabajar en una ventanita (o varias a la vez) del emulador, montando y desmontando los ATR de los respaldos de mis antiguos diskettes, y utilizar varios de mis utilitarios escritos en BASIC (la mayoría con rutinas USR empotradas) y el ensamblador MAC/65.

La consecuencia es que me he demorado más de lo presupuestado, ya que editar programas largos en ventanitas de 40x24 caracteres y con todas las líneas numeradas obliga a ejecutar comandos como LIST algunos cientos de veces para hacerse la idea de cómo va la cosa. Además, ante un error en una rutina USR, me veo obligado a ir al emulador donde tengo corriendo MAC/65, montar el ATR, modificar, compilar, desmontar, ir al emulador donde estan mis utilitarios, montar ahí el ATR con la modificación en formato binario, procesarla para generar código BASIC, desmontar, ir al emulador donde está SITRE, montar el resultado final, incorporar la modificación al programa y probar. Si algo salió mal... repetir!!!

Al menos al tener varias ventanas de emuladores no necesito estar booteando cada vez para cada cosa, pero en parte está así porque para la mayoría de las actividades estoy usando Altirra, en cambio para SITRE estoy usando atari800-a8cas, ya que es el más estable para generar archivos CAS y WAV. No estoy usando el emulador Atari800WinPLus para el desarrollo porque no deja tener 2 ventanas de sí mismo a la vez, pero eventualmente hago pruebas con él, porque es el que está por defecto al hacer doble clic en los XEX, ATR, CAS, etc...

Como no es seguro que 2 emuladores usen el mismo ATR a la vez, un problema en común que tengo con todos los emuladores es que no es simple montar y desmontar los ATR, pues debo usar distintas combinaciones de teclas para llegar a los respectivos menús, y hacer más de una acrobacia para abrir el ATR correcto. Un drag&drop no sirve porque el emulador se reinicia con el ATR que le caiga en la ventana, cuando lo que quiero es montarlo como segunda o tercera unidad en usa sesión activa. Se me ocurrió que cada emulador debiera tener íconos representando cada dispositivo habilitado, ya sea en la barra de estado, en una botonera o en una ventanita externa, y que sea posible arrastrar hacia ellos para montar sin reiniciar y presionarlos para desmontar/desactivar, y si se presionan cunado no tienen nada, que aparezca la ventana estándar para abrir. Pero eso escapa de este hilo.

¿Alguien tiene alguna idea de cómo seguir probando la nueva versión de SITRE? ¿Algún juego (con link) que en su oportunidad haya sido complicado pasar a cinta?

Avatar de Usuario
dogdark
Mensajes: 594
Registrado: Lun Mar 04, 2013 1:36 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por dogdark » Jue Feb 26, 2015 8:20 pm

primeramente, agradecido por el aporte, pasamos a contar mi experiencia

al colocar el atari 800 256k, lo encendí primero con el archivo del cas que el vitoco adjunto en la web, desde el aspqt vía usb para probarlo, dándome el error en el sector 2 de inicio de carga donde se cuelga y no pasa, dije, caspitas si en el emulador funciona porque no con el atari real, realice la siguiente prueba para ver cuantos bancos cuenta mi atari, tome un código que entrego vitoco para ver la cantidad de bancos que cuenta mi atari.

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
3 FOR I=M TO 0 STEP -1:POKE 54017,B(I):POKE 22222,B(I):NEXT I
4 FOR I=1 TO M:POKE 54017,B(I):IF PEEK(22222)=B(I) THEN NEXT I
5 IF I<=M THEN M=I-1:POP
6 PRINT M
el resultado me arroja 13 bancos, mmmm estamos bien, no pasa por eso.

decidí tomar mi casetera xc12 con injektor más el adapter cassette y probaré con el wav que hice, conecto el audio desde mi note hacia el casette, pruebo con winamp, enciendo y veamos....

carga. aparece la bienvenida

Imagen

después aparece la portada del commando

Imagen

la diferencia es que en esta foto aparecen 256k en el mio solo salen 192k yyyyyyy, problema, en esta parte el irg que esta como espacio para reaunar la carga, me dio problemas por que como se detiene el motor el audio de la note sigue, tuve que retroceder para volver a recargar y a la primera error de nuevo, a la segunda paso sin ningún problema, continuamos con la carga, segundo pito sin problemas y de ahí para adelante los pitos largos que estan entremedio no causaron problemas porque no pide la detención del motor de la casetera, al llegar al final cruzando los dedos, esperando que todo cargue bien, aparece el mensaje del juego y urraaaaa cargo sin ningún problema, pude jugar jajjaja lo que no lograba con el aspqt, en resumen funciona de mil maravillas el juego.

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Vie Feb 27, 2015 1:10 pm

dogdark escribió:al colocar el atari 800 256k, lo encendí primero con el archivo del cas que el vitoco adjunto en la web, desde el aspqt vía usb para probarlo, dándome el error en el sector 2 de inicio de carga donde se cuelga y no pasa,
No me había dado cuenta que el AspeQt también emula casseteras con WAV. Qué bueno saberlo. Respecto de tu problema en este intento, vi que AspeQt puede ignorar/customizar las tasas de transferencia respecto de lo que dice el .CAS, y no sé si eso habrá provocado la caída. Tal vez no sea capaz de manejar bloques de largo distino al estándar y lleguen bloques cortados. En todo caso, veo que no es práctico por ahora para los sistemas con recuperación de errores, ya que la documentación dice clarito:
The cassette emulation does not support rewinding or seeking in the images. This may change in the future versions.
dogdark escribió:decidí tomar mi casetera xc12 con injektor más el adapter cassette y probaré con el wav que hice, conecto el audio desde mi note hacia el casette, pruebo con winamp, enciendo y veamos....

carga. aparece la bienvenida

Imagen

después aparece la portada del commando

Imagen

la diferencia es que en esta foto aparecen 256k en el mio solo salen 192k
Entonces la versión que tenías es la que no modifica la presentación:

Imagen
dogdark escribió:yyyyyyy, problema, en esta parte el irg que esta como espacio para reaunar la carga, me dio problemas por que como se detiene el motor el audio de la note sigue, tuve que retroceder para volver a recargar y a la primera error de nuevo, a la segunda paso sin ningún problema, continuamos con la carga, segundo pito sin problemas y de ahí para adelante los pitos largos que estan entremedio no causaron problemas porque no pide la detención del motor de la casetera, al llegar al final cruzando los dedos, esperando que todo cargue bien, aparece el mensaje del juego y urraaaaa cargo sin ningún problema, pude jugar jajjaja lo que no lograba con el aspqt, en resumen funciona de mil maravillas el juego.
Eso que se detenga el motor y no se pueda poner automáticamente en pausa el audio externo es una complicación. En realidad en todas las pausas (pitos lentos) se detiene el motor, se pasa el control al programa, y a la vuelta se enciende otra vez para continuar la carga.

En el caso de Commando+, en las primeras pausas el programa se dedica a buscar los bancos de memoria extendida que están disponibles usando las 256 combinaciones de bits posibles en PORTB, tal vez buscando la mayor cantidad de mods compatibles, y así se arma su propia tablita de bancos en forma dinámica. También activa las pantallas de carga, y todo eso le toma tiempo. Si no fallaron las restantes pausas es porque el tamaño de la pausa fue suficientemente larga como para que el programa active el primer banco encontrado usando un código de apenas 3 instrucciones, y luego cargar un bloque de 8K, después usa 3 instrucciones más para activar el siguiente banco de la tabla y despues carga 8K más, y así... 16 veces en total cargando bancos de 8K, totalizando 128K. ¡Pero son 16! Eso es más que los 12 ya discutidos (descontando los 4 bancos que representan los 64K de memoria real), por lo que pienso que en caso de un Atari real, se está cargando datos en la memoria real a través del banco. Además, los bancos no se usan completos, sino que sólo los primeros 8K de sus 16K. Estoy pensando que intenta emular lo que haría el cartucho del juego original, en que los 128K los divide en bancos de 8K, por lo que completa los 2dos 8K con los mismos datos que corresponden a esa parte de la memoria... si cambia el banco, en la práctica el juego ve que cambiaron 8K y no 16K.
Spoiler: MOSTRAR
Analizando "COMM256K.XEX"...
65535 [$FFFF] (binhead)
8192-8756 [$2000-$2234] (565) PROG/DATA : busca bancos disponibles y activa pantalla de carga
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
10240-10448 [$2800-$28D0] (209) PROG/DATA :
12288-12337 [$3000-$3031] (50) PROG/DATA
32768-40956 [$8000-$9FFC] (8189) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 10240 [$2800]
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-22064 [$4000-$5630] (5681) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-16921 [$4000-$4219] (538) PROG/DATA
17587-24575 [$44B3-$5FFF] (6989) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16522-23632 [$408A-$5C50] (7111) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-24575 [$4000-$5FFF] (8192) PROG/DATA
8192-8198 [$2000-$2006] (7) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 8192 [$2000]
16384-17750 [$4000-$4556] (1367) PROG/DATA
19842-21368 [$4D82-$5378] (1527) PROG/DATA
22528-23201 [$5800-$5AA1] (674) PROG/DATA
736-737 [$02E0-$02E1] (2) -> 10346 [$286A]
A diferencia de Commando+, en la carga del Goonies 130XE hay bloques de 1 byte justo sobre el registro PORTB (54017) como si el loader hiciera un POKE, activando uno de los bancos, y luego carga otro bloque de casi 16K directamente sobre el banco, e itera para llenar los 4 bancos, luego desactiva los bancos de la misma forma y termina de cargar en memoria real. Salvo para la pantalla de carga personalizada al comienzo, no requiere de más pitos lentos. Si bien usa bancos preestablecidos, me llamó la atención que usa los que yo designé como 9, 10, 11 y 12, pues el bit 6 de PORTB lo mantiene siempre encendido. Eso no afecta al 130XE porque ese bit no se usa, y se mapean a los bancos 1, 2, 3 y 4. Pero como dije, los bancos son bancos y da lo mismo cuáles o el orden en que se usen, mientras siempre pueda obtener el banco N cuando requiera los datos que previamente guardé en N.
Spoiler: MOSTRAR
Analizando "GOONIESX.XEX"...
65535 [$FFFF] (binhead)
47872-48089 [$BB00-$BBD9] (218) PROG/DATA
738-739 [$02E2-$02E3] (2) -> 47872 [$BB00]
65535 [$FFFF] (binhead)
38656-39167 [$9700-$98FF] (512) PROG/DATA
65535 [$FFFF] (binhead)
39424-39543 [$9A00-$9A77] (120) PROG/DATA
54017-54017 [$D301-$D301] (1) $E3 "11100011"
65535 [$FFFF] (binhead)
16384-31487 [$4000-$7AFF] (15104) PROG/DATA
54017-54017 [$D301-$D301] (1) $E7 "11100111"
65535 [$FFFF] (binhead)
16384-27135 [$4000-$69FF] (10752) PROG/DATA
54017-54017 [$D301-$D301] (1) $EB "11101011"
65535 [$FFFF] (binhead)
16384-32383 [$4000-$7E7F] (16000) PROG/DATA
54017-54017 [$D301-$D301] (1) $EF "11101111"
65535 [$FFFF] (binhead)
16384-25983 [$4000-$657F] (9600) PROG/DATA
54017-54017 [$D301-$D301] (1) $FF "11111111"
65535 [$FFFF] (binhead)
24576-38655 [$6000-$96FF] (14080) PROG/DATA
65535 [$FFFF] (binhead)
5888-12031 [$1700-$2EFF] (6144) PROG/DATA
65535 [$FFFF] (binhead)
1536-1578 [$0600-$062A] (43) PROG/DATA
736-737 [$02E0-$02E1] (2) -> 1536 [$0600]
De todos modos me alegro que haya funcionado la prueba, aunque la tecnología más moderna no te haya acompañado... Parece que hay que usar esos viejos Maxell, TDK o Sony de 45 minutos por lado para probar el Commando+ :lol:

Avatar de Usuario
dogdark
Mensajes: 594
Registrado: Lun Mar 04, 2013 1:36 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por dogdark » Vie Feb 27, 2015 8:51 pm

no me acuerdo que versión fue la que pase a wav, fue una de las dos cas que subiste,
No me había dado cuenta que el AspeQt también emula casseteras con WAV
en realidad lo que hace el aspqt es tomar una imagen cas y trabajarla como audio hacia el atari, pero no funciona con los copiadores nhp stac etc, solo con archivos sin preload, o sea normales.

veré si logro conseguir un cassette de 90 minutos para pasar el audio, porque solo tengo de 60. espero ver algún día el código en asm para aprender mas del funcionamiento del copiador y sus bancos. se agradece por tu aporte a los que aun, nos gusta usar la casetera como medio de carga, o simplemente para aquellos que no cuentan con disketera y solo usan el periferico de cinta para cargar sus juegos.

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Dom Mar 01, 2015 2:55 am

No me había dado cuenta de lo que yo mismo dije... efectivamente se necesita un cassette de 90 minutos para poder grabar los 130K, ya que es poco más de media hora y no sirve un cassette de 60 minutos. Pero lo que no había calculado es que en 45 minutos se pueden meter máximo 186K de los 208K disponibles (730 de 832 bloques) que indiqué anteriormente, y eso son sólo 12 de los 13 bancos disponibles. Bueno, 12 bancos son justo los que están disponibles en la ampliación , pero en fin, es una restricción física fuera del Atari... al menos yo no conozco cintas de 60 minutos por lado. Se me ocurrió hacer una mejora que permita grabar un juego largo en 2 partes, una en cada lado de la cinta, pero pensé que tendría el mismo problema discutido antes de las interrupciones.

Pero volviendo a la prueba original, quise hacerla yo mismo en el Atari real de 256K que tengo en la casa, así que escarbé en mis viejos casstettes y encontré algunas cintas de 90 minutos que podría usar. Puse los ATR de SITRE y COMMANDO+ en la tarjeta SD que uso en la SIO2SD y cargué SITRE. Aquí me llevé una sorpresa: sólo se reconocieron 9 bancos. Nueve!!!! ¿Qué onda? Cargué un programita de FANDAL para identificar los bancos y él pilló 13... los 4 adicionales son los que dejé al final de mi tabla, los que descarté por ser los mismos que la memoria real.

Se me ocurrió probar si podía cargar el XEX del COMMANDO+ directamente desde SIO2SD con su XEX-Loader incorporado (es como darle doble-clic a un XEX y este carga directo en el emulador), y me apareció el mensaje de que se requieren 256K... Shuuuuuu.... Es decir, ni el juego detectó toda la memoria.

Creo que llegó el momento de abrir el 800XL para ver qué tipo de ampliación tiene. Descubrí que no era el mod de Buchholz, sino que la ampliación de memoria de Newell Industries (el que publicó Z). Pero no está funcionando, no se le puede reconocer toda la memoria disponible al Atari, sólo está reconociendo los bancos 0 y del 5 al 16, siendo que para ese mod los bancos debieran ser del 0 al 4 y del 8 al 16, y eso debiera ser sin contar los 64K de la memoria real. Me di cuenta que había un cable del mod que debería ir soldado a un pin de un chip y que estaba suelto, apenas insertado en el socket junto a la patita del chip. Lo volví a soldar donde iba y no cambió en nada. Quedé pillo.

No puede haber chips de memoria malos, ya que si falla uno, falla toda la memoria, pues son 8 chips en que cada uno guarda un bit de cada byte, y no podría desaparecer un banco completo. A menos que sean los chips de lógica los que están fallando. Eso ya enreda más las cosas.

Quise hacer más pruebas, pero me falló la tarjeta SD... El SIO2SD dejé de reconocerla. Después de echar hartos pericos y gugliar por algunas horas, me chorié y me dio sueño. Al menos volví a armar el Atari y lo dejé en su lugar, pero es en la pieza de los niños y ellos ahora duermen y no puedo molestar. A ver si mañana retomo.

Avatar de Usuario
dogdark
Mensajes: 594
Registrado: Lun Mar 04, 2013 1:36 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por dogdark » Lun Mar 02, 2015 6:37 am

jajja que soy quemao vitoco, bueno como te comentaba antes cuando use tu código para ver cuantos bancos me reconocía, en el mio y reconoció 13 bancos, y en el 130 lo hizo con 4, creo que deberías revisar muy bien esa expansión, hay algo malo por ahí, yo esa que tienes tu, nunca la pude echar andar, por eso arme la de space invaders, e incluso por algunas consultas que me respondió el gentilmente, funcionó a la primera, el único problema que se me genera es la cargar por el siousb, por que con el juego comando a través del usb no carga, pero cuando probé con el wav que hicimos la prueba con el sitre, lo cargue por audio y partió altiro, aunque no los creas lo e cargado ya como 4 veces para jugarlo. y otra cosa, aun hay cassettes de 120 minutos jijiji como dato, pero es muyyyyyy difícil encontrar, el que tenia me lo echaron pala basura ya no daba más. veré si pillo en san diego si queda alguno por ahi.

Avatar de Usuario
SpaceInvader
Mensajes: 217
Registrado: Jue Jul 17, 2014 4:01 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por SpaceInvader » Lun Mar 02, 2015 8:07 pm

Probé el Commando 192K en mi Atari expandido, cargué el wav con casete adaptador en una XL12. La carga funciona, tal cual en el emulador, se para al principio un par de veces, pide retroceder, y sigue cargando, hasta que dice "presione cualquier tecla para jugar". Aquí mi Atari muestra pura basura en pantalla, y el juego no funciona. Pero, esto es normal, mi expansion hace tiempo que está con algunos problemas, algunas cosas cargan y otras no, tengo que revisarla. Pero el cargador Sitre hace su trabajo correctamente, sin errores.
Última edición por SpaceInvader el Lun Mar 02, 2015 10:17 pm, editado 1 vez en total.

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Lun Mar 02, 2015 10:02 pm

dogdark: en el 130XE debió reconocerte 5 bancos (4 de memoria expandida y 1 de real). Las cintas de 90 minutos son más delicadas que las de 60 porque son más finas para meter más metros en el mismo espacio... las de 120 deben ser delicadísimas!!! En todo caso, me hiciste recordarlas... sí las había visto en marca SONY. Las rojas eran de 60 minutos, las verdes de 90... y las de 120 eran ¿¿¿azules???

SpaceInvader: Yo intenté en el Atari real algunas variantes de Commando de 192K que Fandal publicó en AtariAge, y hubo una en particular que logró cargar, pero al partir el juego también mostró basura en la pantalla. Es como que estuviera sacando la data del playfield desde el banco equivocado. Obviamente no es jugable. Es por eso que pienso que deberías correr los tests que pusiste en tu página, a ver si algo ha cambiado. A propósito, yo no alcancé a hacer las pruebas hoy en el Atari real.

¡Gracias muchachos por las pruebas!

En SITRE yo asumí sólo 2 tipos de memoria extendida: 130XE y Buschholz/RAMBO-XL, y los valores predefinidos son compatibles con ambas expansiones, puestos en un orden conveniente para ello. Después de descubrir que el Atari que tengo en casa venía el mod Newell, me di cuenta que los valores en PORTB para activar cada banco no son los mismos aunque usen los mismos bits (daría igual si fuesen los mismos valores en otro orden). Eso me lleva a intentar un cambio en el algoritmo, es decir, no tener la tabla de valores precalculados en duro, sino que descubrirlos en una rutina de inicialización al igual que lo hace Fandal en la adaptación del juego Commando. Veré eso en paralelo a la prueba física de la memoria en el Atari real.

Avatar de Usuario
SpaceInvader
Mensajes: 217
Registrado: Jue Jul 17, 2014 4:01 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por SpaceInvader » Mar Mar 03, 2015 12:18 am

Traigo buenas noticias! Funcionó COMMANDO 192K!! :mrgreen:
Imagen

Me di cuenta que usé la expansión del ZZ en la primera prueba, cambié el modulo de expansión por la de Buchholz, probé de nuevo con el wav, y cargó al toque!
Ya me parecía raro, si a Dogdark le funcionó, a mi también debería funcionarme, ya que tenemos el mismo hardware. Pero habia olvidado que tenía mi Atari con con la expansión de ZZ... Esto no quiere decir que la expansión zz/Newell esté mala, parece que el acceso a los bancos extra es diferente.

Ahora que recuerdo, cuando hice mi página web de la expansión de memoria, mi intención era cargar Commando, y mostrar fotos, pero no pude cargar el ejecutable... El casete Sitre (wav de 79.1 MB, 31:20 minutos) solucionó el problema, buen trabajo, Victor.

Saludos.

Avatar de Usuario
dogdark
Mensajes: 594
Registrado: Lun Mar 04, 2013 1:36 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por dogdark » Mar Mar 03, 2015 12:29 am

o sea estaríamos hablando que los hardware son totalmente diferentes unos de otros y por lo tanto, cada software que se haga dependerá exclusivamente del tipo de ampliación que se incorpore en los atari, es por eso que a lo mejor el proyecto de turbo software no dio resultado alguno, debió haber sido por la extensión de memoria que usaba, y como decía vitoco el manejo de los bancos debe hacerse a mano con cada uno de ellos, habría que ver vitoco si se puede realizar estándar para ambas o más extensiones.

Avatar de Usuario
renix
Mensajes: 4675
Registrado: Vie Ene 25, 2013 1:39 am

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por renix » Mar Mar 03, 2015 11:57 am

Pongan mas monos del juego...

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Mar Mar 03, 2015 2:02 pm

Encontré un viejo post en que se explica un mod que se le puede hacer a la ampliación Newell para dejarla compatible con la de Buchholz y el 130XE. En resumen, al parcecer los 2 tipos de ampliación usan en forma distinta el bit 5 del registro PORTB, que es el que habilita el acceso a memoria extendida al ANTIC en los XE. En el post indican cambiar un cable por otros 2 seleccionables con un switch que hay que agregar, pero a uno de ellos hay que pasarlo por un negador, lo cual hacen utilizando uno disponible en el mismo Atari. La variante negada compatibiliza la expansión. Eso explica por qué cuando buscaba la expansión por fotos, simpre había un switch al lado del modulador RF, lo cual yo no tengo.

Voy a revisar si con esta información puedo acceder a todos los bancos, pero lo dudo, ya que si sólo logré reconocer 13 (12 bancos + 1 real) usando otros utilitarios, algo más debe haber. Lo único que podría explicar la falta de 4 bancos es que éstos correspondan realmente a la RAM base y que no se pueda acceder a ellos a través de los bancos (excepto el que cae justo en esa ventana de memoria) mediante una restricción en el mismo circuito.

Por lo tanto, si puedo verificar que los 12 bancos corresponden exclusivamente a memoria extendida, voy a ver la factibilidad de hacer ese cambio en mi equipo, aunque lo más probable es que lo haga sin switch, sino que directamente negaré el pin usando el inversor disponible y lo dejaré fijo.

Sin embargo revisaré bien las conclusiones que se pueden obtener de todo esto, ya que la idea es que SITRE sea lo más estándar posible, independiente de que haga o no el cambio en la ampliación Newell.
renix escribió:Pongan mas monos del juego...
Este hilo no es para discutir el juego Commando, sino que del copiador SITRE, aunque derivó hacia el uso de bancos memoria extendida para copiar juegos más grandes. Lo curioso es que el cartucho Commando pesa 128K, pero en la versión XEX aparece dividido en 16 bancos de 8K en lugar de 8 bancos de 16K. Si quieres ver el juego por tu cuenta, te invito a cargar cualquiera de las imágenes publicadas en este hilo en alguno de los emuladores usando la ampliación Rambo. 8-)

Avatar de Usuario
fcatrin
Mensajes: 655
Registrado: Jue Ene 24, 2013 2:19 pm
Ubicación: Quilpué
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por fcatrin » Mar Mar 03, 2015 4:00 pm

... o ver en YouTube. La versión es bastante buena. Yo solo hubiese cambiado los colores del marcador para que no se viera tan café todo.
Spoiler: MOSTRAR

Avatar de Usuario
renix
Mensajes: 4675
Registrado: Vie Ene 25, 2013 1:39 am

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por renix » Mar Mar 03, 2015 7:11 pm

Y derivó en commando vitoco :)

Veo que con algo mas de RAM el A8 no tiene mucho que envidiar al C64 graficamente...

Avatar de Usuario
SpaceInvader
Mensajes: 217
Registrado: Jue Jul 17, 2014 4:01 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por SpaceInvader » Mié Mar 04, 2015 3:43 pm

vitoco escribió:Encontré un viejo post en que se explica un mod que se le puede hacer a la ampliación Newell para dejarla compatible con la de Buchholz y el 130XE.
Hice ese mod, para dejar más compatible la expansión del ZZ, sólo hay que agregar un inversor al pin 15 de la PIA.
Funciona, cambian las direcciones de los bancos, pero igual no me funcionó Commando. Pero es una excepción, todos los test toman como válida la expansión, y se puede usar normalmente.
En ambos casos, siempre se detectan sólo 12 bancos. Aqui muestro unas fotos de comparación:

Imagen

Se puede ver que los bancos quedan prácticamente iguales a la de Buchholz. Los programas están en el memramchecktest.atr, son exttest.com y xram.com.
(http://spaceinvader.comuf.com/Atari_800 ... M_Soft.rar) pass Space

Aqui se puede ver el swith, lo puse en la misma placa de la expansión, es el jumper rojo:
Imagen

Entonces Victor, es muy probable que, aunque hagas el mod en tu atari, igual no funcione el cargador Sitre... Pero podrías probar.

Saludos.

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Mié Mar 04, 2015 3:54 pm

Mi sospecha va por el lado que el mod Newell protege los 4 bancos asignados a la memoria base del 800XL y no se puede escribir en ellos, en tanto que el de Buchholz si puede hacerlo, pero es peligroso. El problema es que no he encontrado documentación de ello, como tampoco de la variante de 320K que en vez de reemplazar los chips de memoria originales, agrega los nuevos (64K + 256K) y se comportaría como en los emuladores.

Si fuera el caso de que estuvieran bloqueados los 4 bancos, no se podría usar el Commando, ya que la conversión a XEX intenta escribir 8K en 16 bancos. Eso se lo voy a consultar a Fandal en AtariAge.

Avatar de Usuario
renix
Mensajes: 4675
Registrado: Vie Ene 25, 2013 1:39 am

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por renix » Mié Mar 04, 2015 9:04 pm

Esta buenisimo este hilo :)

Avatar de Usuario
vitoco
Mensajes: 1970
Registrado: Lun Ene 28, 2013 5:47 pm
Contactar:

Re: [ATARI] Copiador SITRE para juegos en cassette

Mensaje por vitoco » Sab Mar 07, 2015 12:56 am

Misterio resuelto... encontré un documento en que efectivamente se dice que el mod Newell bloquea el acceso a los bancos que representan la memoria real, dejando sólo 192K para RAM extendida. Como ya había dicho, el problema es que los bits que usa para activar los bancos no es el mismo que el mod de Buchholz/Rambo-XL, pero hay un mod para Newell que reordena los bancos simplemente mediante la negación de uno de los bits de PORTB, y los deja igual a Rambo-XL como lo confirmó SpaceInvader, aunque mantiene el bloqueo de los bancos que se usan para la memoria base. La cosa es que el documento que me confirmó lo del bloqueo es uno que dice como desbloquearlo y dejarlo 100% compatible con Buchholz. Y además encontré otro que transforma el 130XE a 320K (aunque me parece que en realidad se refiere al 65XE).

¿Y para donde voy con todo esto? Que un mismo mod tiene distintas variantes, que algunos mods tienen bancos inseguros ya que representan la memoria base y sobreescribirlos es peligroso, pero que hay otro que no tiene bancos representando la memoria real y sí es seguro utilizarlos. Es decir, mi supuesto inicial de la tabla precalculada es parcialmente válida, ya que sirve para algunos mods. ¿Y cómo extenderlo a varios/todos los mods? Quizás deba usar el algoritmo de Fandal para identificar bancos (probando todas las combinaciones de bits posibles en PORTB) o tal vez tener distintas tablas precalculadas y hacer pruebas específicas para seleccionar la adecuada.

Pero volviendo al Atari que tengo en casa con el mod de Newell, confirmé que se trata del mod original, sin ningún upgrade, y que me entrega 192K de XRAM (RAM extendida), aunque yo no la estaba detectando completa en SITRE. Hice algunas pruebas y vi qué estaba pasando.

Con mi tabla original de 13 valores en SITRE, la prueba detectaba sólo 9 bancos (8 de XRAM), y eso es porque lo que hace el algoritmo es meter en orden inverso un valor propio a cada banco y después los recorre en orden normal buscando el primer banco que no tenga el valor esperado, confirmando que ese banco no está dsponible y asumiendo que los restantes tampoco lo están. Eso era válido cuando se consideraba sólo las ampliaciones del 130XE y de Buchholz a la vez por la compatibilidad de sus bits en PORTB.

Lo que descubrí es que los bancos 1 al 4 de mi tabla son los mismos que del 9 al 12, es decir, Newell no está bloqueando el acceso a la RAM reservada para la base, sino que la redirige a otros bancos de XRAM. Por lo tanto, al escribir en los bancos en orden inverso, predomina el número de banco menor en caso de haber duplicados, y por eso el algoritmo aborta en el banco 9 y se queda sólo con 8 de XRAM (más 1 de base).

Para que SITRE detectara 4 los bancos faltantes, reemplacé los 4 primeros valores de la tabla por los que había dejado como 13 al 16, correspondientes a la memoria base en el mod de Buchholz, pero XRAM en Newell. De esta forma, los bancos 1 al 4 están OK, 5 al 8 siguen disponibles igual que antes, y del 9 al 12 ahora no fueron modificados, por lo lo que se completan los 12 bancos de XRAM.

La tabla se modifica a algo como lo que sigue:

Código: Seleccionar todo

       | POKE  |        Buch  New  | D=0     V=0 E=0         B=0 R=1
 Banco | 54017 | 130XE  holz  ell  |  7   6   5   4   3   2   1   0
-------|-------|-------------------|---------------------------------
   0   |  177  |  RAM   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     8   |  1   1   0   0   0   0   0   1
   6   |  197  |         9     9   |  1   1   0   0   0   1   0   1
   7   |  201  |        10    10   |  1   1   0   0   1   0   0   1
   8   |  205  |        11    11   |  1   1   0   0   1   1   0   1
   9   |  225  |        12     4   |  1   1   1   0   0   0   0   1
  10   |  229  |        13     5   |  1   1   1   0   0   1   0   1
  11   |  233  |        14     6   |  1   1   1   0   1   0   0   1
  12   |  237  |        15     7   |  1   1   1   0   1   1   0   1
-------|-------|-------------------|---------------------------------
  13   |  129  |         0     0   |  1   0   0   0   0   0   0   1
  14   |  133  |         1     1   |  1   0   0   0   0   1   0   1
  15   |  137  |         2     2   |  1   0   0   0   1   0   0   1
  16   |  141  |         3     3   |  1   0   0   0   1   1   0   1
El problema es que para Buchholz y Rambo-XL no se puede usar los bancos 13 al 16, y para Newell hay una discontinuidad... ¡Eso sin considerar los mods de 320K o superiores!

El próximo paso será buscar la mejor forma de resolver este problema sin saber a priori qué tipo de XRAM es la que se está utilizando.

Responder