fcatrin escribió:@xt5
Por lo que pude entender, el flash se lee de a bloques y no es posible mapearlo en memoria?
la memoria flash (EEPROM) se lee como cualquier cart, mapeandola en memoria, el diseño permite emular cualquier sistema de banking con paginas de 8KB.
la SD es la que se lee en bloques de 512 bytes (y solo en orden y que usa una memoria NAND).
una memoria SD es una memoria NAND (las mismas de los discos SSD) conectada a un controlador que tiene 2 modos (simplificando un poco) de operacion:
1- normal: se usan 4bits (bidireccional) como bus de datos y funciona hasta velocidades altisimas.
2-
SPI: se usa 1bit de salida, otro de entrada, un clock, y un chip select, es este modo el que usaremos.
la idea es que el CPLD implementa el protocolo SPI, con un registro para recibir datos, otro para enviar y uno de control, es asi que casi todos los microcontroladores funcionan, pero nosotros tenemos un problema y es que el CPLD es bastante "pequeño" y no podemos implementar un buffer (FIFO) como lo hace una implementacion de SPI comun y corriente, por lo que dependeremos del Atari para manejar el timing, y el controlador SPI solo se limitara a serializar los bits.
por lo descrito en el parrafo anterior, el Atari es quien debe manejar todo el protocolo de la memoria SD, no es gran cosa de todas maneras.
fcatrin escribió:
@Vitoco
Entiendo algo similar. Yo aplicaría esta estrategia:
1) Se carga un bootloader pequeño desde el catridge y se ubica en una posición fija de memoria
2) El bootloader pequeño carga un loader más elaborado desde un archivo en la SD, desconectando el cartridge. Este loader Incluye el despliegue del menú
3) Una vez seleccionado el juego, se carga un loader minimo pero que sea relocalizable, descartando el segundo loader. Este loader tiene sólo la lógica para cargar sectores del SD + la lógica para cargar un archivo XEX (bloques + ejecución)
lo de 2 niveles de bootloader no es necesario ya que las EEPROM "modernas" mas chicas que se encuentran son 512KB y alli te cabe el loader completo, no hay problema con cambiar el loader cuantas veces queramos desde la EEPROM ya que se autoprograma desde el mismo Atari con facilidad,
aqui hay un ejemplo de ello, obviamente nada nos impide tener una especie de "autorun" que cargue algun loader nuevo de la SD.
por conveniencia del diseño (pocos pines del CPLD), la memoria EEPROM y la tarjeta SD no pueden estar activos a la vez, asi que por lo menos las rutinas que leen desde la SD deben copiarse a la RAM.
vitoco escribió:¿La idea es que el loader copie desde SD a flash para que el Atari lo vea como un cartucho original?
la idea es leer desde la SD a la RAM y ejecutar.
pero ademas tenemos un flashcart
for free que se puede autograbar desde el mismo Atari y segun en el espacio que quede en CPLD se pueden implementar algunos de los mappers historicos como los de Turbosoft, etc.
el problema de este cart es que sin un prototipo en la mano, es dificil empezar a construir el software, y luego hay sumar que teniendo el prototipo en la mano seguramente habra que hacerle una cirugia menor.
despues hago un esquema de la arquitectura, pero creo que con estas descripciones se entiende la vision global.
--
antes que alguien pregunte en que se diferencia de un SIO2SD.
-la "pega" del SIO2SD la hace un microcontrolador mas potente que el Atari, en este cart la pega la haria el mismo Atari.
-el SIO2SD se conecta por el SIO, puede tomar buena velocidad, pero nosotros por estar conectados directamente al bus de la CPU podemos tomar mejor velocidad.
-el bootloader del SIO2SD es una disquetera simulada, nuestro bootloader estaria en el cartridge.
: 
