ATARI -¿Crear un cain para expansion de 800xl?

[fcatrin]

me sigue saliendo el error 3 es ese el problema y va directamente con el usr

Me cito a mi mismo de un post de más arriba

Justamente: "a value is not within a specific range"

Es porque L es muy grande. Hay que pasarlo en dos partes, dos números de 16 bit, y por supuesto recibirlo como tal al otro lado. Por otra parte, eso requería manejar ese caso en el código de máquina que espera recibir un único valor de 16 bit.

[dogdark]

eee no se una idea,, se me ocurrio hacer esto, locura nu mas

[fcatrin]

Eeeso! buena!! dale dale no más!

(BTW apruebame el usuario en tu sitio porfa)

[dogdark]

ya ahora entre en el mismo problema de siempre con el poke

poke 54017,221, ahora con el 4 le estoy diciendo que serian 16 bits de entrada por banco, después JJ le indico el banco donde se posicionaran los bytes, ahora le agrego 16 y culmino con 1 para el extra o sea seria así

poke 54017,221+4*jj+16*1 - POKE 54017,221 + 4*ADDRESS + 16*MODE.

que tan lejos estoy???

address section memory
0 0 - 16383
1 16384 - 32767
2 32768 - 49151
3 49152 - 65535
4 65536 - 81919
5 81920 - 98302
6 98303 - 114685
7 114686 - 131068

[fcatrin]

No entendí bien tus calculos, pero ésta es la explicación completa de cómo se hace el cálculo. Leer con calma, sin apresurarse.

Supongamos que quieres acceder al banco "n", donde n va desde 0 a 15, o sea 16 bancos en total (*)

Como hay que saltarse un bit, no es llegar y multiplicar. Entonces el número "n" hay que dividirlo en dos partes para que podamos controlar los bits en forma separada.

Si definimos BH = bank high y BL = bank low, el valor n se representa como un número de 4 bits formado de la siguiente forma

Código: Seleccionar todo

3 2 1 0   :   N
. . X X   :   BL
X X . .   :   BH

Una forma de calcular BL y BH es:

Código: Seleccionar todo

bh = n / 4     (eliminamos los bits 0 y 1)
bl = n - bh*4  (eliminamos los bits 2 y 3)

Finalmente, al poner los valores en 54017 hay que considerar que bl caerá en el bit 2 y 3, y bh caerá en el bit 5 y 6. Lo podemos ver así:

Código: Seleccionar todo

7 6 5 4 3 2 1 0    : 54017
. . . . X X . .    :    BL
. X X . . . . .    :    BH

Calculamos ahora el decimal que corresponde a cada bit base (2 para BL y 5 para BH) usando decimal = bit^2 tenemos:

Código: Seleccionar todo

decimal base para bl = bit^2 = 2^2 = 4
decimal base para bh = bit^2 = 5^2 = 32

Por lo tanto, el poke que necesitas es:

Código: Seleccionar todo

poke 54017, bh * 32 + bl * 4

Es similar al calculo que habías hecho, pero corregido. Por casualidad aparecen muchos valores 4, y creo que es bueno entender de donde sale cada valor 4.

Como podrás ver, para 130XE el cálculo es lo mismo, sólo que al tener 4 bancos, bl = n y bh es siempre cero, por lo que el calculo se simplifica así:

Código: Seleccionar todo

poke 54017, bl*32 + bl * 4 =>
poke 54017,  0*32 +  n * 4 =>
poke 54017,          n * 4

Saludos
--
Franco

(*) Los bancos siempre serán de 16KB porque así está diseñado el hardware.

[vitoco]

Supongamos que quieres acceder al banco "n", donde n va desde 0 a 15, o sea 16 bancos en total (*)
...
(*) Los bancos siempre serán de 16KB porque así está diseñado el hardware.

16 bancos!!!

Estamos hablando entonces de 16 x 16KB = 256KB de memoria extendida, y sumándole los 64KB base de los XL/XE, totalizan 320KB. Uff! Eso es mucha memoria...

Sin embargo, el mod de Claus Buchholz que indicó dogdark es de sólo 256KB en total, ya que no agrega chips de memoria extra sino que los reemplaza por unos con 4 veces más capacidad, por lo que deja 4 bancos para los 64KB de la memoria principal del 800XL y sólo 192K para los bancos de 16KB, es decir sólo hay 12 bancos extras y están numerados del 4 al 15 (no es del 0 al 11)

Lo otro es que en vez de tener que recalcular el valor que hay que meter en el registro 54017, mejor inicializar un arreglo con los valores precalculados, algo así:

Código: Seleccionar todo

1 DIM B(13):FOR I=0 TO 12:READ X:B(I)=X:NEXT I:DATA 177,161,165,169,173,193,197,201,205,225,229,233,237

¿De dónde saqué esos valores? Armé una tablita con los bits de los bancos de acuerdo a la documentación (como lo explicó Franco), pero incorporé además los otros bits de control, totalizando 13 bancos:

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  

La numeración que hice de los bancos fue arbitraria: el banco 0 corresponde a la RAM original del Atari en la ventana $4000-$7FFF (16384-32767), en tanto que los bancos a partir del 1 son de la memoria extra (que se ven en la misma ventana). Además, los bits 0 y 1 están con valores fijos asumiendo que la ROM del SO y el ATARI BASIC están presentes. No sé si será el caso de CAIN, pero SITRE necesitaba modificar el SO para ajustar la velocidad de grabación, por lo que copiaba la ROM en la RAM, y para ese caso, a cada valor en la DATA habría que restarle 1.

Quise probar esos valores, pero no lo puedo hacer ahora en mi 800XL real con 256KB, así que usé el emulador Altirra. Me llamó la atención que Altirra, entre todas sus configuraciones, no tenga la opción de este mod que fue muy popular. Sin embargo, sí está el mod RAMBO de 320KB. Hasta donde entiendo, el mod RAMBO/XL es compatible con el de Buchholz (si es que no es el mismo) y también sólo llega a 256KB, pero no sé cómo se instala ese mod de 320KB... probablemente sea soldando piggy-back todos los chips de memoria sobre los existentes, pero dejando al menos 1 pin libre en cada uno para controlar con PORTB (54017).

De todos modos, usé ese modo en Altirra y funcionó exactamente como esperaba. Quise ir más lejos, y completé la tabla con la combinación que faltaba en los bits 5 y 6 (ambos en cero), y logré direccionar los 16 bancos de memoria extra. O sea, en total hay 17 bancos de 16KB, con 262144 bytes de buffer para un copiador. Feliz como lombriz...

El programa de prueba que usé es el siguiente (se puede copiar aquí y pegar en Altirra):

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=0 TO M:POKE 54017,B(I):PRINT I,B(I):POKE 17000,B(I):NEXT I
4 FOR I=0 TO M:POKE 54017,B(I):PRINT I,B(I),PEEK(17000):NEXT I

El arreglo B() tiene la lista de valores precalculados, y la variable M indica cuántos bancos de memoria extra se disponen, así que si se usa:

- 130XE estándar: M=4
- 800XL con mod de Bushholz: M=12
- 800XL con mod RAMBO 320K: M=16

Las líneas 1 y 2 cargan el arreglo. Obviamente se pueden eliminar de la DATA los valores que no se usarán, es decir, hay que dejar los primeros M+1 valores.

La línea 3 selecciona cada banco y pone el mismo valor de la DATA en una dirección cualquiera dentro de la ventana (elegí la dirección 17000 porque sí).

La linea 4 vuelve a seleccionar cada banco, y muestra tanto el valor que debiera tener en la memoria modificada como el que realmente leyó para ese banco. Si ambas columnas tiene el mismo valor, el banco está correcto, pero si para alguna fila cambia, hay conflicto entre bancos, y el valor leído dará una pista de cuáles serían.

ya ahora entre en el mismo problema de siempre con el poke

poke 54017,221, ahora con el 4 le estoy diciendo que serian 16 bits de entrada por banco, después JJ le indico el banco donde se posicionaran los bytes, ahora le agrego 16 y culmino con 1 para el extra o sea seria así

poke 54017,221+4*jj+16*1 - POKE 54017,221 + 4*ADDRESS + 16*MODE.

que tan lejos estoy???

Con todo lo que expliqué, te encuentro harto lejos... Al igual que Franco, no entiendo de dónde sacas ese 221 como base. Ese valor no aparece en mi lista. Supongo que ahí también tienes un ERROR 3.

Creo que te complicas demás con el ADDRESS y el MODE (MODE tiene que ver sólo con el 130XE, y no conozco ningún programa que use el modo de video con el bit 5). Quédate con el concepto de "banco", y la data siempre estará entre las direcciones 16384 y 32767.

Suerte con tu CAIN4, y recuerda que en un 130XE, el copiador tendrá 5 bancos (81920 bytes) direccionables en la ventana de 16KB, por lo que para copiar el juego Goonies versión XEX de 72670 bytes no se requiere expansión de memoria en ese computador (o emulado).

[dogdark]

cada día me van quedando las cosas mas claras, el domingo hare un resumen de los que he entendido para que vayamos paso a paso. por el momento solo me quedo una duda franco.

Calculamos ahora el decimal que corresponde a cada bit base (2 para BL y 5 para BH) usando decimal = bit^2 tenemos:

Código: Seleccionar todo

decimal base para bl = bit^2 = 2^2 = 4
decimal base para bh = bit^2 = 5^2 = 32

si dices 5^2=32 de donde sacaste ese valor, porque 5^2 es 25 perrin , bit=5 elevado a 2 es 25 y no 32.. esa duda me quedo franco, no será 2^5, jijiji

entonces sería

decimal base para bh = 2^bit = 2^5 = 32

[fcatrin]

cada día me van quedando las cosas mas claras, el domingo hare un resumen de los que he entendido para que vayamos paso a paso. por el momento solo me quedo una duda franco.

Calculamos ahora el decimal que corresponde a cada bit base (2 para BL y 5 para BH) usando decimal = bit^2 tenemos:

Código: Seleccionar todo

decimal base para bl = bit^2 = 2^2 = 4
decimal base para bh = bit^2 = 5^2 = 32

si dices 5^2=32 de donde sacaste ese valor, porque 5^2 es 25 perrin , bit=5 elevado a 2 es 25 y no 32.. esa duda me quedo franco, no será 2^5, jijiji

entonces sería

decimal base para bh = 2^bit = 2^5 = 32

Ahh porque lo escribí mal, quise decir 2^5

Partí leyendo el post de vitoco pensando en que lo escribías tu y dije "que rápido aprendió" jajaja, después caché que era de vitoco.

[fcatrin]

La numeración que hice de los bancos fue arbitraria: el banco 0 corresponde a la RAM original del Atari en la ventana $4000-$7FFF (16384-32767), en tanto que los bancos a partir del 1 son de la memoria extra (que se ven en la misma ventana). Además, los bits 0 y 1 están con valores fijos asumiendo que la ROM del SO y el ATARI BASIC están presentes. No sé si será el caso de CAIN, pero SITRE necesitaba modificar el SO para ajustar la velocidad de grabación, por lo que copiaba la ROM en la RAM, y para ese caso, a cada valor en la DATA habría que restarle 1.

Cierto, está copiada la ROM en RAM y por eso el bit 0 siempre está apagado (en cero)

En realidad, y aquí entramos a hilar fino, no me gusta la numeración de bancos que usaste, porque obliga a manejar casos especiales dependiendo del computador, cuando se puede entender to de una forma más abstracta: bancos secundarios a partir del cero.

Yo asumí que para efectos de cálculo los bancos extras siempre parten en cero, de esa forma es consistente con el valor que se escribe en 54017 y oculta el detalle de si estamos en un 130XE o en un 800XL + expansión de memoria, así:

Código: Seleccionar todo

Banco | 130XE | 256K | Binario | BH | BL | 7 6 5 4 3 2 1 0 | POKE
    0 |     0 |    0 |    0000 | 00 | 00 | . 0 0 . 0 0 . . | 32 * 0 + 4 * 0
    1 |     1 |    1 |    0001 | 00 | 01 | . 0 0 . 0 1 . . | 32 * 0 + 4 * 1
    2 |     2 |    2 |    0010 | 00 | 10 | . 0 0 . 1 0 . . | 32 * 0 + 4 * 2
    3 |     3 |    3 |    0011 | 00 | 11 | . 0 0 . 1 1 . . | 32 * 0 + 4 * 3
    4 |       |    4 |    0100 | 01 | 00 | . 0 1 . 0 0 . . | 32 * 1 + 4 * 0
    5 |       |    5 |    0101 | 01 | 01 | . 0 1 . 0 1 . . | 32 * 1 + 4 * 1
    6 |       |    6 |    0110 | 01 | 10 | . 0 1 . 1 0 . . | 32 * 1 + 4 * 2
    7 |       |    7 |    0111 | 01 | 11 | . 0 1 . 1 1 . . | 32 * 1 + 4 * 3
    8 |       |    8 |    1000 | 10 | 00 | . 1 0 . 0 0 . . | 32 * 2 + 4 * 0
    9 |       |    9 |    1001 | 10 | 01 | . 1 0 . 0 1 . . | 32 * 2 + 4 * 1
   10 |       |   10 |    1010 | 10 | 10 | . 1 0 . 1 0 . . | 32 * 2 + 4 * 2
   11 |       |   11 |    1011 | 10 | 11 | . 1 0 . 1 1 . . | 32 * 2 + 4 * 3

Entonces el calculo siempre será 32*BH + 4*BL
La única excepción sería al momento de usar la memoria principal en donde bastaría usar el valor 16. En peudocodigo y usando el valor de n = -1 para la memoria principal, tenemos;

Código: Seleccionar todo

setBank(n) {
  if (n<0) b = 16;
  else {
    bl = n % 4;
    bh = n / 4;
    b = bh*32 + bl*4;
  }
  poke 54017, b;
}

Luego recorremos los bancos disponibles desde -1 hasta el máximo del equipo (3 para 130XE, 11 para 256K)

Suerte con tu CAIN4, y recuerda que en un 130XE, el copiador tendrá 5 bancos (81920 bytes) direccionables en la ventana de 16KB, por lo que para copiar el juego Goonies versión XEX de 72670 bytes no se requiere expansión de memoria en ese computador (o emulado).

Buena observación!!

Saludos
--
Franco

[vitoco]

En realidad, y aquí entramos a hilar fino, no me gusta la numeración de bancos que usaste, porque obliga a manejar casos especiales dependiendo del computador, cuando se puede entender to de una forma más abstracta: bancos secundarios a partir del cero.

Yo asumí que para efectos de cálculo los bancos extras siempre parten en cero, de esa forma es consistente con el valor que se escribe en 54017 y oculta el detalle de si estamos en un 130XE o en un 800XL + expansión de memoria, así:

Spoiler: MOSTRAR

Código: Seleccionar todo

Banco | 130XE | 256K | Binario | BH | BL | 7 6 5 4 3 2 1 0 | POKE
    0 |     0 |    0 |    0000 | 00 | 00 | . 0 0 . 0 0 . . | 32 * 0 + 4 * 0
    1 |     1 |    1 |    0001 | 00 | 01 | . 0 0 . 0 1 . . | 32 * 0 + 4 * 1
    2 |     2 |    2 |    0010 | 00 | 10 | . 0 0 . 1 0 . . | 32 * 0 + 4 * 2
    3 |     3 |    3 |    0011 | 00 | 11 | . 0 0 . 1 1 . . | 32 * 0 + 4 * 3
    4 |       |    4 |    0100 | 01 | 00 | . 0 1 . 0 0 . . | 32 * 1 + 4 * 0
    5 |       |    5 |    0101 | 01 | 01 | . 0 1 . 0 1 . . | 32 * 1 + 4 * 1
    6 |       |    6 |    0110 | 01 | 10 | . 0 1 . 1 0 . . | 32 * 1 + 4 * 2
    7 |       |    7 |    0111 | 01 | 11 | . 0 1 . 1 1 . . | 32 * 1 + 4 * 3
    8 |       |    8 |    1000 | 10 | 00 | . 1 0 . 0 0 . . | 32 * 2 + 4 * 0
    9 |       |    9 |    1001 | 10 | 01 | . 1 0 . 0 1 . . | 32 * 2 + 4 * 1
   10 |       |   10 |    1010 | 10 | 10 | . 1 0 . 1 0 . . | 32 * 2 + 4 * 2
   11 |       |   11 |    1011 | 10 | 11 | . 1 0 . 1 1 . . | 32 * 2 + 4 * 3

Entonces el calculo siempre será 32*BH + 4*BL
La única excepción sería al momento de usar la memoria principal en donde bastaría usar el valor 16. En peudocodigo y usando el valor de n = -1 para la memoria principal, tenemos;

Código: Seleccionar todo

setBank(n) {
  if (n<0) b = 16;
  else {
    bl = n % 4;
    bh = n / 4;
    b = bh*32 + bl*4;
  }
  poke 54017, b;
}

Luego recorremos los bancos disponibles desde -1 hasta el máximo del equipo (3 para 130XE, 11 para 256K)

Cueck!!! Como comenté en mi otro post, los bancos del mod de Bushholz no parten del 0, sino que del 4. Fíjate que en mi tabla BH=0 está puesto en los cuatro últimos bancos, y que no se usan en ese mod en un 800XL real. Tienes que partir con BH=1, y fue diseñado así para que sea compatible con programas escritos para el 130XE. Ese "detallito" rompe tu esquema y el pseudocódigo se complicará para identificar qué expansión se está utilizando.

Por otro lado, y al contrario de lo que dices, la nomenclatura que usé para numerar lo "bancos" es compatible tanto con el 800XL modificado como con el 130XE a la vez, por lo que fácilmente se puede chequear qué tipo de ampliación se tiene y determinar el máximo M, que incluso puede ser 0 en un 800XL estándar. El resto del programa queda tal cual... nada de IF posteriores al chequeo. O sea, el copiador que use este método podría correr tal cual en un 800XL sin ampliación si el XEX pesa a lo más 16384 bytes. ¡Flexibilidad!

Una forma de determinar dinámicamente el máximo M usando mi nomenclatura es:

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

Las líneas 1 y 2 ya las conoces del post anterior, la línea 3 es similar, pero modifica los bancos en orden inverso, y las líneas 4 y 5 determinan cuál es el máximo banco que se puede usar, modificando el valor de M. El POP es sólo para limpiar el stack de BASIC por abortar un ciclo FOR-NEXT. A esta altura no importa que el arreglo tenga elementos de sobra si es que M bajó de 16.

Lo probé en Altirra usando las configuraciones de 130XE (128KB) , RAMBO (320KB) y 800XL estándar (64KB), y en todos ellos obtuve el M correcto. Si alguien lo puede probar en distintos Atari reales, que comente aquí los M que obtuvo para cada caso.

Como se puede apreciar, en ninguna parte tuve que hacer cálculos estrambóticos. Si lo quieres en pseudocódigo:

Código: Seleccionar todo

setBank(n) {
  poke 54017, b[n];
}

con b el arreglo de valores precalculados, n=0..M y M el número de bancos disponibles.

En todo caso, los bancos son sólo zonas para almacenar data y no importa su orden físico en el hardware, mientras se puedan identificar inequívocamente y sean accesibles con ese identificador. Por ejemplo, si sólo hay 4 bancos extra (130XE), basta tomar los 5 primeros números de la data y los puedes desordenar, pero una vez fijados, todo andará como reloj. Si van del 0 al 4 o del -1 al 3 da lo mismo, pero en ATARI BASIC los subíndices en los arreglos parten de 0, y por eso opté por este orden.

Por último, si se quisiera validar expansiones de memoria con una configuración distinta e incompatible, bastaría simplemente agregar otras líneas de DATA y usar la que corresponda mediante RESTORE para cada caso pre-identificado.

Después de todo lo que escribí en el otro post, me quedaron dando vuelta unas ideas locas:

- No tengo la menor idea de qué tipo de modificación tiene el 800XL de 256KB que uso en casa. Nunca lo he abierto porque realmente no es mío. Supongo que después de 22 años de préstamo en que lo he cuidado como a una joya, tal vez el dueño no se moleste si exploro un poco. (VH, avísame si lees esto)

- Me dieron ganas de modificar SITRE para poder usarlo en este 800XL ampliado.

- Sólo hemos hablado de data usando bancos (y tratando la memoria normal como banco 0), pero hay más memoria que podría estar disponible fuera de la ventana. Depende de cómo esté construido el copiador para saber cuánta memoria extra se tendrá. Sin embargo, no recomiendo usar esa memoria para almacenar el XEX, ya que requerirá conocer parámetros adicionales por banco, como la dirección por donde se accede y el tamaño... esos ahora son fijos. Mejor dejar esa memoria para el programa copiador en sí y para los LOADER que se copiarán a cinta precediendo el juego.

- Hay otro mod de 512KB que usa además el bit 7 del registro 54017 para acceder a los segundos 256KB de la ampliación, es decir, 32 bancos de 16KB. Usando el método que describí en mi post anterior, se podría acceder a 29 bancos (los otros 3 bancos corresponden a la memoria del Atari fuera de la ventana), y para ello en el programa de prueba bastaría poner M=28 y agregar otra línea de DATA con los mismos valores, pero saltándose el primero, omitiendo los 4 últimos y restándole 128 a los demás (o sea, agregar DATA 33,37,41,45,65,69,73,77,97,101,105,109). No lo puedo probar porque Altirra tampoco emula esa ampliación.

Se puso entretenido esto, pero creo que terminaremos confundiendo a dogdark

[renix]

Se que puede ser medio off topic pero como A8 ha despertado mi curiosidad hace tiempo, y veo que muchos saben mucho, me gustaria embarcarme en hacer un PCB a partir de los esquematicos de atari que incorpore en su hardware todas las mejoras que han salido este ultimo tiempo, directamente en su hardware, a saber la expansion de ram, sio2sd o myide, svideo,mod stereo, etc., con una carcaza atariana pero hecha en impresora 3D o derrchamente reciclar una carcaza atari, con chiperia original reciclada, nada de implelemtaciones fpga... Y sin redIseño de nada ni reinventar la rueda, solo incorporar hardware nuevo

Sorry por el off topic... Pero tengo todo en la cabeza como hacerlo...

[dogdark]

vitoco, lo que pasó fué lo siguiente, quise pasar el goonies que es solo para 130xe, con los copiadores que tengo a mano y ninguno me dio resultados, como no entiendo assembler y no se descompaginar ni nada, se me ocurrió por lo que me acordaba, que cain me podría dar resultados porque usaba la carga en la ram extendida del atari y tenia ahí 64 kb para empezar, probé con cain y no me dio resultados, saltando en el momento de grabar el juego, error 3 en la linea 295, probé con cain II y cain III y me pasaba absolutamente lo mismo, entonces se me ocurrió la idea de crear un cain IV, tanto que sea para 130xe como para 800 con expansión, y cree este post, con la muy buena voluntad de franco, que me a tenido una paciencia enorme, me ha enseñado a nivel muy básico a entender como es el comportamiento entre un atari y otro, por eso le pedí en un comentario anterior que me explicará detalladamente como trabajaba, porque si me ponía a decir que este byte es de allá y se cruza con este otro la verdad no le iba a entender nada, por eso posteamos como y en donde hay que comenzar, como se comporta en poke 54017 entre ambos atari y como se debe dirigir uno a un banco y con que byte, me a costado enormemente tratar de comprender, como se debe hacer, no es fácil, porque no se trata de decir pone este poke 54017,193+4*JJ y eso te lo arregla, recién vamos en el poke después tenemos que entrar en el usr, pero si no logro entender el comportamiento y la dirección que debo usar en lo que está detrás del poke, nunca entenderé el usr, que eso es assembler puro. Esa es la idea que habíamos tenido desde un principio con franco, hacer un post educativo a nivel muy básico, para que todos los que estamos en pañales aprendamos de esto, también te agradezco la información que nos das, porque es de mucha utilidad y con eso más se aprende, estoy agradecido enormemente de todos ustedes con todo esto y me di cuenta, que lo que sabia de basic no es ni el 5% de todo lo que abarca, soy bueno para hacer menus o cosas pequeñas, pero debo reconocer que esto me quedo muy grande, pero quiero aprenderlo, en la paciencia, el tiempo y el deseo esta el aprendizaje, me demoraré pero lo intentare y si no lo logró, reconoceré que la cabeza ya no me da, pero en el intento nadie se a muerto. gracias muchachos por la gentileza y ayuda.

[fcatrin]

Se puso entretenido esto, pero creo que terminaremos confundiendo a dogdark

Hasta yo quedé confundido!!! jajajajja

[fcatrin]

dogdark, paciencia no más, de repente paf! todo va a cobrar sentido.

Siempre cuento la historia de la vez que entendí a calcular el valor decimal a partir de un binario. Era un artículo de una revista en donde hablaban de la redefinición de caracteres, pero no entendía como llegaban a las lineas DATA finales. Al leer el texto sabía que había un párrafo en donde estaba la clave, porque antes de eso no tenían el valor calculado y después de eso asumían que el valor ya estaba calculado. No sé cuantas veces leí ese párrafo, pero recuerdo la frase clave en donde decían "se deben sumar los pesos de cada pixel", lo leía, lo leía y no sabía qué quería decir. A veces dejaba de lado la revista y a los días la volvía a tomar hasta que un día vi que los valores eran más altos cuando el primer pixel estaba encendido, y finalmente pude establecer la relación entre esos pixeles y los números decimales. Ahora parece obvio, pero hubo un momento en que no tenía ningún sentido.

Después de eso, la técnica de la insistencia nunca me ha fallado. Paciencia.

Saludos
--
Franco

[fcatrin]

Se que puede ser medio off topic pero como A8 ha despertado mi curiosidad hace tiempo, y veo que muchos saben mucho, me gustaria embarcarme en hacer un PCB a partir de los esquematicos de atari que incorpore en su hardware todas las mejoras que han salido este ultimo tiempo, directamente en su hardware, a saber la expansion de ram, sio2sd o myide, svideo,mod stereo, etc., con una carcaza atariana pero hecha en impresora 3D o derrchamente reciclar una carcaza atari, con chiperia original reciclada, nada de implelemtaciones fpga... Y sin redIseño de nada ni reinventar la rueda, solo incorporar hardware nuevo

Sorry por el off topic... Pero tengo todo en la cabeza como hacerlo...

Sería ideal poder conseguir algunas de esas cosas empaquetadas acá en Chile. Recuerdo que había entusiasmo por levantar una tienda de hardware retro, es un sueño que espero que algún día ocurra.

[vitoco]

vitoco, lo que pasó fué lo siguiente, quise pasar el goonies que es solo para 130xe, con los copiadores que tengo a mano y ninguno me dio resultados

Puchas, no quería meterme a mirar el código de CAIN porque aún tengo en la cabeza revivir mi copiador SITRE (a insistencia de AsCrNet) y no quiero "contaminarme" con ideas de otros. Por lo mismo, el único hilo que no he leído en este foro es el tuyo sobre Turbo Software.

Pero por lo visto, tendré que meterme a mirar el código de CAIN para ver a qué se debe realmente el error 3 y si se puede hacer un fix rápido. Como dije, un 130XE (sin RAMDISK) debe ser suficiente para copiar el Goonies.

Esa es la idea que habíamos tenido desde un principio con franco, hacer un post educativo a nivel muy básico, para que todos los que estamos en pañales aprendamos de esto

Por eso metí la cuchara... me pareció bueno lo que estás haciendo, y me motiva a retomar lo que me apasionaba y que nunca abandoné (aunque haya tenido que meter mi HW en cajitas en la bodega). De vez en cuando puedo hacerme un tiempito y hacer aportes, aunque parece que aquí fui muy técnico cuando quise explicar qué estabas haciendo mal, porque no era llegar y sumar para todos los casos. En realidad eso debió quedar en un post independiente sobre cómo usar el registro PORTB (dirección 54017) para manejar la memoria expandida en el 130XE y los 800XL ampliados. Pero bueno, aquí estamos para servirle...

Entiendo que programar en Assembler es otra cosa, pero aunque no lo creas, las rutinas que uno utiliza en los USR son bastante simples y fáciles de entender. Si me animo, escribiré un post sobre el uso de USR en BASIC de Atari. Después podrían ir rutinas de ejemplo... yo tenía mi propia biblioteca de rutinas que usaba prácticamente en todos mis utilitarios.

Se puso entretenido esto, pero creo que terminaremos confundiendo a dogdark

Hasta yo quedé confundido!!! jajajajja

Y eso que se me olvidó mencionar que este método para manejar bancos de memoria con una lista precalculada también simplificaría el código en Assembler:

Código: Seleccionar todo

setBank
  TAX ; asume que acumulador trae el número de banco, con 0=memoria principal.
  LDA bancos,X
  STA 54017
  RTS
bancos
  .BYTE 178,162,166,170,174,194,198,202,206,226,230,234,238,130,134,138,142

Nada de AND, ORA, ROL, branches ni nada... A propósito, le sume 1 a cada valor. A ver si adivinan por qué!!! El torpedo es mi tablita del otro post.

Lo divertido de todo esto es que no tengo recuerdo cómo lo hice hace más de 25 años con SITRE. Y eso que fue pura teoría, porque no tenía el 130XE para desarrollar ni hacer pruebas. O sea, copiaba puros juegos chicos en mi 800XL

[renix]

Hola Franco, en eso estamos con toledo, lento pero avanzando...

[dogdark]

gracias vitoco por el apoyo, y en realidad no te había entendido mucho, solo que me aclaro que los bancos de memoria del 800ex no se trabajan de la misma manera que en el 130xe, me gustaría seguir a posterior también el post que crees sobre las rutinas que se puedan crear con usr, como decía franko, el cain hay que modificar el usr que es el problema más grande y también modificar el poke 54017 que solo esta para usar los 64kb extras del 130xe, el copiador sitre no lo tengo y no se como funciona, no se si esta en basic o en asm. en cuanto al proyecto que estábamos realizando con el turbo software, nunca lo pudimos terminar, porque no entendimos cual era el problema que suscitaba que al comenzar la grabación el pito inicial duraba como 3 segundos y empezaba a mandar los datos y el irg era demasiado corto, en eso quedamos lo demás, gracias a la ayuda de todos se pudo armar, y con el ascrnet nos llevamos tardes y tardes revisando ese código hasta donde pudimos, y puedes descargar el código desde el mismo post que esta armado en asm y debe ser cargado con el dos 256k para que funcione, en cuanto a cain IV la idea era modificar par dejarlo para 130xe y 800ex, mi idea era la siguiente, en los 64kb primarios del 130 dejar todo el código escrito mas los binarios que necesita este copiador, y en el secundario usando los primeros 4 bancos usarlo para un 130 siempre y cuando el juego se menor a 64kb si este juego sobrepasa los 65kb que empiece el ingreso después del banco 4, o sea el ingreso sea total desde el 5 en adelante, pero después me di cuenta, que hay que usar desde el banco 1 de la expansión y no empezar desde el 5 en este caso, para futuros juegos que pueden ser mas largos, como los que están sacando los polacos, si tengo tanta memoria y no la puedo usar y se deben preguntar pa que???? en el caso si el juego es muy bueno, hay personas que solo tienen casettera en la comunidad y la única manera de cargarlos es vía wav, por ejemplo mi amigo suppawer, que por largo tiempo siempre nos referimos a los cassettes y armamos nuestras colecciones, esas son dos razones importantes que me impulsaron a crear un cain IV y en eso estoy aunque me demore 100 años lo intentare. y Renix, no seria mala idea la tuya, porque necesito por lo menos hacer plaquitas en doble paca para algunos proyectos míos pero no tengo maquina para eso, y si tienen alguna tienda, uno podría mandar los diseños para que sean creados y vendidos a posterior, por ejemplo mi expansión es de chinos por no tener una placa de doble capa y esta llena de cables jajaj se ve fea pero funciona bien.

[fcatrin]

Y eso que se me olvidó mencionar que este método para manejar bancos de memoria con una lista precalculada también simplificaría el código en Assembler:

Código: Seleccionar todo

setBank
  TAX ; asume que acumulador trae el número de banco, con 0=memoria principal.
  LDA bancos,X
  STA 54017
  RTS
bancos
  .BYTE 178,162,166,170,174,194,198,202,206,226,230,234,238,130,134,138,142

Nada de AND, ORA, ROL, branches ni nada... A propósito, le sume 1 a cada valor. A ver si adivinan por qué!!! El torpedo es mi tablita del otro post.

Lo divertido de todo esto es que no tengo recuerdo cómo lo hice hace más de 25 años con SITRE. Y eso que fue pura teoría, porque no tenía el 130XE para desarrollar ni hacer pruebas. O sea, copiaba puros juegos chicos en mi 800XL

Ohh siiii! Esa parte se simplifica mucho!

Ojo ahi dogdark!

Sobre la parte del error 3, es simplemente porque el valor que se está pasando como argumento ya no se puede representar como un número de 16 bit, entonces hay que separarlo en dos partes de 16 bit

"When arguments are used in a USR function, each argument can be any value that equates to a 16-bit number. "

También hay que recibirlo como dos valores de 16 bit en el lado del ASM, además de cambiar las partes en el cálculo para considerar esa info adicional.

Yo lo podría hacer, pero eso sería arruinar la fiesta de dogdark, o no?

Saludos
--
Franco

[vitoco]

Fe de errata: el que me estaba cateteando por SITRE fue Suppawer

Estuve mirando el código de SITRE para ver cómo manejaba los bancos, y es muy parecido al esquema que publicaste:

Código: Seleccionar todo

POKE PORTB,225+BANCO*4

donde PORTB=54017 y BANCO va de 0 a 3. Por lo tanto, el valor 221 que explicaste antes debe ser porque los bancos los tienes numerados de 1 a 4 y el resultado será el mismo.

Además, parece que SITRE no está usando el banco de memoria principal para almecenar la data, por lo que tampoco te serviría para copiar el Goonies. Tal vez estoy mirando una versión anterior de mi copiador, porque recuerdo haber hecho algo al respecto para otro juego que pesaba más de 64K. Es una lata que los DOS estándares del Atari no almacenaban la fecha y hora de los archivos, así que yo le ponía ese dato en las primeras líneas a todos mis programas. Voy a tener que buscar más, pero en diskettes reales, porque aún no termino de traspasar todo a PC.

Yo lo podría hacer, pero eso sería arruinar la fiesta de dogdark, o no?

Exacto... pero para que lo haga él solito, le urge meterse en los USR y un poco de Assembler.