Retronia

El cartucho multijuegos de Turbosoft permitió poner en un único cartucho de 128K varios juegos y presentarlos con un menú al encender el Atari XL/XE. Hubo varias series de ellos, y usualmente cada uno contenía un par de juegos interesantes y se rellenaba con varios juegos pequeños.

Hace varios años, algunos miembros de la comunidad estuvieron destripando el cartucho, generando los esquemáticos y obteniendo la data de las EPROM de todos los conocidos en formato "*.BIN". Con la información de cómo funcionaba este cartucho se permitió emularlo en Altirra y la data copiada de ellos funciona tal como en un Atari real.

Hace algunas semanas, otro integrante de la comunidad se propuso modificar el contenido de estos cartuchos, y poner en uno de ellos los juegos que el quisiera, modificando la lista del menú adecuadamente, pero se topó con algunas cosas que desconocía y consultó al respecto tanto en éste como en otros foros. En esa oportunidad me puse a revisar el contenido de la copia modificada del cartucho y posteriormente la copia original para ver cómo funcionaba realmente ese cargador y como se estructuraban los programas y datos en el cartucho.

En realidad no avancé mucho, ya que bastaba saber cómo operaba la componente hardware del multicart para que surgiera la idea de armar un cargador renovado que utilizara el mismo cartucho, y es aquí donde comienza este proyecto.

La idea es:
- Renovar el menú de juegos.
- Aprovechar algunas técnicas avanzadas de almacenaje como compresión de datos.
- Construir una aplicación que permita generar cartuchos virtuales (.BIN) con lista personalizada de juegos.

En una segunda etapa, elegir entre:
- Grabar un .BIN en la EEPROM de un cartucho viejo
- Construir un nuevo cartucho utilizando tecnología actual (ej: memoria flash).

Ya he investigado un poco de todo lo anterior, e iré posteando los avances.

Buena, excelente idea, por mi parte me ofrezco de "probador" para cualquier binario, tengo varios carts Turbosoft con base para testear en hardware real.
Hace tiempo que puedo hacer dos tipos de cartridges Atari con menú, el "Switchable XEGS multicart" (original de Raster), que está en mi sitio web, de 1Mb maximo, y el otro es el clon de Atarimax, que soporta hasta 8 Mbit, y que postié hace algún tiempo aquí en Retronia.
Seria bueno hacer clónicos de los carts Turbosoft, ojalá que este proyecto avance.

Agradezco la oferta de las pruebas en HW real. Y te adelanto que de tus páginas sacaré parte de la info que necesito para armar lo nuevo. También necesitaré ayuda para entender algunas cosas en las que aún tengo dudas sobre el banqueo o paginación (desde el punto de vista de la operación del HW), pero que en nada afecta al desarrollo de este proyecto.

SpaceInvader escribió:Hace tiempo que puedo hacer dos tipos de cartridges Atari con menú, el "Switchable XEGS multicart" (original de Raster), que está en mi sitio web, de 1Mb maximo, y el otro es el clon de Atarimax, que soporta hasta 8 Mbit, y que postié hace algún tiempo aquí en Retronia.

¿Tienes archivos .ROM (o .BIN) de ambos sistemas? En una búsqueda rápida no encontré, y a pesar que tengo mi propia idea de menú, quiero verlos andando en emulador.

ACA VA MI APORTE PARA ESTAS PSEUDO REPROS...
Fuentes FreeCAD y archivos STEP

Casi no pongo roms para descargar en mi sitio, porque antes, te podían banear y te borraban todo. Pero actualmente están mas relajadas las restricciones...
Aqui te dejo unos ejemplos de multicarts de 1 Mbit, de Atarimax y Switchable:

¡Gracias muchachos por los aportes!

Quiero aclarar que mi idea es potenciar el Turbocart, no hacer un nuevo supercartucho, ya que de esos hay varios. O sea, quiero sacarle el máximo provecho a un viejo cartucho, dándole un aspecto renovado, y maximizando el uso que se le pueda dar a los 128K de RAM (*).

Para lograr esto, he estado dándole vueltas a varias cosas:

- Menú minimalista: todo un reto si quiero que a la vez se vea renovado y atractivo.

- Cargador XEX de máxima compatibilidad: es muy probable que me base en parte del código de SITRE, que ha demostrado que se la puede con juegos que en otros cargadadores fallan.

- S.O. de cartucho: Tenía pensado hacer una especie de sistema operativo que leyera bloques desde los bancos del cartucho como lo haría el DOS desde diskettes, pero si la idea es aprovechar al máximo el espacio del cartucho, no pueden sobrar bytes en el último bloque de cada juego, lo que obliga a tratar el cartucho como si fuera un dispositivo de bytes. Deberé ver bien como estructurar el cartucho.

- Compresión de datos: es posible ganar espacio si los datos dentro del cartucho se guardan comprimidos. Estoy evaluando alternativas como comprimir los XEX (como lo hice con algunos programas que se autodescomprimen al momento de correr) o comprimir la data en forma general y que el cargador vaya descomprimiendo durante la carga. Esto último puede ir de la mano con el S.O. mencionado en el punto anterior.

Ya comencé a hacer algunas pruebas para determinar la ruta a seguir y qué opciones tomaré de lo recién mencionado.

Lo que sí tengo claro es que no habrá un "Turbocart Studio" elegante que funcione en algún ambiente de ventanas, ya que escapa de mi ámbito. La última vez que programé una aplicación con ventanitas, métodos y propiedades fue en mi penúltima práctica profesional hace más de 20 años... eso fue en "Microsoft Cirrus". Ahora me toca inspeccionar código y resolver problemas de programas desarrollados en alguno de los lenguajes de Visual Studio, pero eso es muy distinto a partir con algo desde cero. No quiero desgastarme en eso, así que todo será en línea de comandos. Quizás al final yo o alguien más de por acá le ponga alguna GUI, pero no es mi foco.

(*) En el post original dije que tal vez podría usar tecnología actual como memoria flash. Eso se haría en caso que no hayan muchos cartuchos originales disponibles para actualizar sus EPROM, pero de hacerlo, creo que sobrará mucha memoria que no se usará. Ya veremos...

Cuenta conmigo vitoco para hacer un pcb según el tipo de memoria que elijas, me parece excelente y pertinente que todo sea minimalista y nada de software tipo winkk para hacer las tortas, de hecho seria genial tener una zaga de turbo-cartuchos de Retronia Monolitica, nada de multicarts... eso seria una seria de cartuchos con listados de juegos de nuestra elección, que ojala incluyan juegos de los últimos concursos y desarrollos actuales para plataforma A8... y packs de descargas con la ROM, el pcb para fabricarlo en casa y los fuentes de la carcaza con su artwork.

Hoy me senti bastante mejor de la manos, ha funcionado un ultimo tratamiento alternativo a operarme, asi que pude, con algo de dificultad si, modelar la caja, inspirada en las cajas de cartucho turbo y la caja del cartucho Perguntón para C=64

Saludos y vamos con esto que se puso muy entretenido....

Se puso interesante y tomó prioridad el tema de la compresión, y creo que eso ya define un roadmap:

(1) Determinar el "mecanismo" de compresión.
(2) Establecer la estructura del .ROM o .BIN.
(3) Desarrollar un cargador acorde a (1) y (2).
(4) Armar un menú ad-hoc.
(5) Automatizar o facilitar la creación de una ROM.

¿Me falta algo?

renix escribió:Hoy me senti bastante mejor de la manos, ha funcionado un ultimo tratamiento alternativo a operarme, asi que pude, con algo de dificultad si, modelar la caja,

Renix, me alegro que te sientas mejor, pero no fuerces las cosas. Si lo recomendado es operarse para resolver un problema en vez de contenerlo con tratamientos alternativos, evalúalo. Busca otros casos y sus respectivos resultados.

estoy conciente de ello... la operacion no es solucion segura a la "sejuela" asi que esto ultimo ha ido muy bien... sino, me opero las manos, pero es la ultima alternativa...

vitoco escribió:Se puso interesante y tomó prioridad el tema de la compresión, y creo que eso ya define un roadmap:

(1) Determinar el "mecanismo" de compresión.
(2) Establecer la estructura del .ROM o .BIN.
(3) Desarrollar un cargador acorde a (1) y (2).
(4) Armar un menú ad-hoc.
(5) Automatizar o facilitar la creación de una ROM.

¿Me falta algo?

creo que el orden lógico según tus puntos es 2, 3 y 1 dependen de 2, 4, 5. se que el orden lo pones porque ya tienes en la cabeza todo lo que piensas hacer, pero creo que hay que ver mas opciones como ejecutar las ROM desde el cartucho en vez de hacer el loader.

- S.O. de cartucho: Tenía pensado hacer una especie de sistema operativo que leyera bloques desde los bancos del cartucho como lo haría el DOS desde diskettes, pero si la idea es aprovechar al máximo el espacio del cartucho, no pueden sobrar bytes en el último bloque de cada juego, lo que obliga a tratar el cartucho como si fuera un dispositivo de bytes. Deberé ver bien como estructurar el cartucho.

lo veo como overhead, ya tienes la data accesible desde la CPU de la manera mas directa posible, el acceso es solo un puntero que incrementa y de muy vez en cuando se topa un salto de banco, hacer un "driver" es como mucho creo yo.

cree un esquemático en Eagle, estoy terminando mi "librería" con el footprint de un cartucho atari (no encuentro las medidas físicas), lo rutearé en cuanto consiga las medidas. es fiel al original, salvo:
-la memoria es una flash de 512KB (fácil de conseguir en Santiago), tiene soporte a todas las lineas de dirección, paquete PLCC
-los IC discretos tienen paquete SOIC, (disponibles en Santiago)
-tiene habilitada la posibilidad de autograbar el cartucho
usa exactamente los mismos ICs lógicos que el original, solo que tiene mas tamaño para datos, mas facilidad de soldar, menos superficie, y usa componentes que no son difíciles de encontrar sin pedirlos afuera.

quería hacer algo mas choro, tipo cartucho para el VHS Turbo software, pero no se si sea para otro hilo, tengo muchos CPLD y GALs que pueden servir para una versión mas freestyle y menos apegada al Turbo Cartridge original (o con compatibilidad).

suerte con todo renix, ojalá salga todo de la mejor manera, eres de las pocas personas que le da muy buen uso a sus manos con miles de proyectos, tienes que tenerlas buenas!!

Ya, la pega del pcb es tuya xt5

Un abrazo

xt5 escribió:creo que el orden lógico según tus puntos es 2, 3 y 1 dependen de 2, 4, 5. se que el orden lo pones porque ya tienes en la cabeza todo lo que piensas hacer, pero creo que hay que ver mas opciones como ejecutar las ROM desde el cartucho en vez de hacer el loader.

No entendí tu secuencia y relaciones de dependencia.
Es verdad que ya tengo bastantes ideas en la cabeza como para planificar lo que viene y darles un orden.

Respecto de ejecutar las ROM sin un loader de XEX, esa alternativa es válida sólo para los juegos que originalmente sean ROM y se disponga del dump original del cartucho, pero restringido a cartuchos de 8K y sin lógica propia de bancos u otros condimentos, y se podrían poner hasta 15 de ellos en una sola EPROM. Esto se debe a la compatibilidad que quiero mantener con el cartucho turbocart original.

Cuando conversamos en la junta pasada respecto del uso de componentes actuales para construir un cartucho compatible, me pareció buena idea, pero que tenga 512K de memoria obliga a cambiar la definición y deja de ser compatible si quieres usar más de 128K. De todos modos no lo descarto como una fase 2.

Estuve mirando el esquema de tu cartucho flash. ¿Qué uso le darás al switch que está en RD5? ¿Tiene que ver con la habilidad de escribir en la memoria flash?

Lo de hacer un nuevo cartucho para procesar la señal de video VHS me parece genial. También fue discutido hace algunos años en la comunidad, pero renovar utilizando como fuente la señal de un DVD. Insisto en lo genial del proyecto, pero no le veo aplicación práctica en el día de hoy, en que todo tiende a ser más rápido y más pequeño, y las alternativas existentes son muchas. En su momento fue una gran solución, pero ahora no me veo yendo a una junta con un reproductor de VHS o de DVD bajo el brazo

vitoco escribió: Cuando conversamos en la junta pasada respecto del uso de componentes actuales para construir un cartucho compatible, me pareció buena idea, pero que tenga 512K de memoria obliga a cambiar la definición y deja de ser compatible si quieres usar más de 128K. De todos modos no lo descarto como una fase 2.

La compatibilidad es casi la misma, cambia:
-tienes mas bancos, la forma de switchearlos es la misma, en vez de 0h a Fh es de 0h a 3Fh
-pierdes la posibilidad de deshabilitar el cartucho

vitoco escribió: Estuve mirando el esquema de tu cartucho flash. ¿Qué uso le darás al switch que está en RD5? ¿Tiene que ver con la habilidad de escribir en la memoria flash?

Cumple la funcion de deshabilitar el cart de forma manual, se hace manual porque una gate de tipo NAND se "recicla" para controlar el grabado. Es necesario poder deshabilitar el cart para poder partir el atari ignorando el cart al booteo.

vitoco escribió: Lo de hacer un nuevo cartucho para procesar la señal de video VHS me parece genial. También fue discutido hace algunos años en la comunidad, pero renovar utilizando como fuente la señal de un DVD. Insisto en lo genial del proyecto, pero no le veo aplicación práctica en el día de hoy, en que todo tiende a ser más rápido y más pequeño, y las alternativas existentes son muchas. En su momento fue una gran solución, pero ahora no me veo yendo a una junta con un reproductor de VHS o de DVD bajo el brazo

Si, obvio que para DVD, y la verdad que como aplicacion practica creo que nada le gana a las soluciones con tarjetas SD.

xt5 escribió:

vitoco escribió:Cuando conversamos en la junta pasada respecto del uso de componentes actuales para construir un cartucho compatible, me pareció buena idea, pero que tenga 512K de memoria obliga a cambiar la definición y deja de ser compatible si quieres usar más de 128K. De todos modos no lo descarto como una fase 2.

La compatibilidad es casi la misma, cambia:
-tienes mas bancos, la forma de switchearlos es la misma, en vez de 0h a Fh es de 0h a 3Fh
-pierdes la posibilidad de deshabilitar el cartucho

Tu mismo lo dices: es "casi" la misma. Hice la del flojo y en vez de analizar el esquemático del cartucho turbocart para deducir su lógica y ver con que direcciones de memoria se activan y desactivan los bancos, busqué un poco más y me encontré con un documento del emulador Atari800 que dice:

+---------------------------------------------------------------------------+
| Type 50: Turbosoft 64 KB cartridge |
+---------------------------------------------------------------------------+

This bank-switched cartridge occupies 8 KB of address space between $A000
and $BFFF. The cartridge memory is divided into 8 banks, 8 KB each. Banks
are selected by an access to an address at $D500-$D5FF. Bits 0-2 of the
address select the bank mapped to $A000-$BFFF. Bit 4 disables the cartridge
and enables RAM. Bits 3, 6 and 7 are ignored. The cartridge starts with
bank 0 enabled.

Reference: http://www.retrogames.cl/turbosoft.html

+---------------------------------------------------------------------------+
| Type 51: Turbosoft 128 KB cartridge |
+---------------------------------------------------------------------------+

This bank-switched cartridge occupies 8 KB of address space between $A000
and $BFFF. The cartridge memory is divided into 16 banks, 8 KB each. Banks
are selected by an access to an address at $D500-D5FF. Bits 0-3 of the
address select the bank mapped to $A000-$BFFF. Bit 4 disables the cartridge
and enables RAM. Bits 6 and 7 are ignored. The cartridge starts with bank
0 enabled.

Reference: http://www.retrogames.cl/turbosoft.html

Como esos números de tipo de cartucho son los mismos que había visto en Atirra cuando ofrece seleccionar al partir, fui directamente al código fuente de ese emulador para corroborar y vi que no es tan así, ya que deshabilita el cartucho al acceder a cualquier dirección de memoria entre $D510 y $D5FF, ya sea en el cartucho de 128K o en el de 64K (en éste sólo se ignora el bit 3 de la dirección).

Sólo para efectos de compatibilidad con los distintos loaders de los cartuchos existentes, no alteraría esa definición en un nuevo cartucho de mayor capacidad. Para crecer, mejor utilizar alguna de las otras definiciones para tipos existentes o definir un tipo propio (y contarle a Phaeron para que lo incorpore en Altirra).

Encontré interesante la posibilidad de utilizar compresión de datos para "aumentar virtualmente la capacidad" del cartucho de 128K. Las alternativas que manejaba eran:

1- Comprimir toda la data del cartucho como si fuera un ZIP, lo cual entregaría la mayor tasa de compresión utilizando algoritmos tipo LZ con diccionario, pero incorpora complejidad extra para descomprimir al vuelo con poco buffer.

2- Comprimir cada XEX al estilo de mi viejo BINPAK. Este utilitario utiliza un método de compresión para ejecutables del Atari que inventé en la época de SITRE, tomando la idea de ZIP2EXE que se usaba entonces en PC. Un ejemplo actual es la versión oficial de Toy'Swap que entregué a ABBUC, que de más de 21K bajó a menos de 18K (84% del tamaño original), lo que no es malo, pero tampoco es mucho por tratarse de un algoritmo tipo RLE. La gracia es que el XEX se carga en memoria usando cualquier loaded (incluso el DOS) y luego se autoexpande para ubicarse donde originalmente estaba definido que cargara, deshaciendo de a poco su buffer a medida que se consumen los bytes, pero sin usar buffers adicionales.

3- Modificar BINPAK para incorporar diccionario al estilo LZ. Me estuve cabeceando un par de días para ver cómo introducir un diccionario en el XEX, pero que no necesitara buffers adicionales, y para lo cual tenía que ver cómo deshacer el buffer original tratando de retener los patrones lo más posible. Estaba en eso cuando se me ocurrió que en vez de tomar los patrones desde el diccionario, los tomara directamente desde la primera copia y tras lo cual se eliminó del buffer original. En el fondo estaría extendiendo el algoritmo RLE de BINPAK para repetir patrones ya extraídos.

Investigando un poco más sobre LZ y sus variantes para evaluar la primera alternativa, recordé haber visto un juego escrito en TurboBASIC XL que fue presentado recientemente en NOMAM y que recreaba parcialmente el juego Caverns of Mars y que usaba el algoritmo LZ4 para descomprimir el mapa del juego. Debo haber estado un día completo tratando de entender cómo funcionaba, pues se parecía bastante a mi BINPAK, hasta que di con el truco: hace precisamente lo que había ideado como modificación para BINPAK, aunque lo implementaba sutilmente distinto.

Comencé a hacer pruebas de concepto con LZ4, ya que si bien es un algoritmo relativamente nuevo, está suficientemente masificado por su rapidez. Pero me di cuenta que no sería factible hacer streaming usando este método. ¿Qué quiero decir? Que no se podrá ir descomprimiendo el archivo XEX original para el loader porque el esquema de punteros que utiliza se perdería a menos que utilizara un gran buffer, que es justamente lo que no tenemos en los XL.

Observando rutinas para otras arquitecturas de máquinas pequeñas, vi que están haciendo algo parecido a lo de BINPAK: cargar el archivo LZ4 en memoria alta y descomprimir hacia la baja, o bien invertir el algoritmo para cargar en memoria baja y descomprimir hacia la alta de atrás para adelante. Así las zonas de datos comprimidos y descomprimidos no se topan durante la descompresión.

El problema con los XEX es que no necesariamente toda la data está junta, sino que se usa el esquema de archivos binarios con la estructrura cabecera-inicio-término-data-inicio-término-data-... y que si se cargan ciertas ubicaciones de memoria, se deduce dónde y cuándo inicializar y correr el programa o juego.

Por lo tanto, decidí que lo mejor es combinar los métodos: usar LZ4 en cada tramo de memoria indicada en el XEX, y dejarle la tarea al loader para que haga el doble trabajo. Es decir, hay que construir un loader especial para que lea y vaya descomprimiento al vuelo cada bloque en la RAM. Y ojo que esto podría servir incluso para cargar directamente en memoria expandida.

Para que eso funcionara, tuve que definir un nuevo formato para los XEX... lo denominé LZ4X y ya voy en la revisión 2. Escribí un programita en perl usando una biblioteca LZ4 y probé con Toy'Swap... éste bajó a menos de 13K (59% del tamaño original).

Para estimar el tamaño virtual de un cartucho de 128K bajo este esquema, tomé una carpeta que tenía unos 200 juegos y los procesé individualmente generando los respectivos LZ4X. El que más se comprimió fue Flak que quedó en un 38% del tamaño original. Kaboom y BoulderDash bajaron al 46%, Dimension X al 54%, Zaxxon al 61%, Gremlins al 74%, Pacman al 76%, Bruce Lee al 81%. El que menos se achicó fué Star Raiders que llegó apenas al 95% del tamaño original. En todo caso, la mitad de los juegos procesados están en el rango del 70% al 85%. Mención especial tiene el Toy'Swap ya procesado previamente por BINPAK: LZ4 sólo logró bajarlo al 96%, aunque respecto del original es el 80%, bastante más grande que el del 59% que se logra en forma directa sólo con LZ4.

En promedio, el ahorro fue de casi 30%. Si esa tasa se mantuviera, el cartucho rendiría unos 180K!!! A ese tamaño virtual, obviamente hay que restarle lo que ocupe el menú y el loader.

A propósito del menú, se me ocurrió que éste también sea un XEX comprimido con LZ4 usando el mismo esquema, por lo que cargaría con el mismo loader... Haciendo esto sería natural omitir el menú y hacer que en su lugar cargue cualquier XEX para tener ese juego en su propio cartucho

Ahora a definir bien el formato de almacenamiento en el cartucho (ya sabemos que no puede ser lineal porque están los 6 bytes especiales al final del primer banco) y luego a programar un loader...

Veo que ya lo tienes cocinado, pero nunca está de más...

Habías visto esta implementación de deflate para 6502?

https://github.com/pfusik/zlib6502

fcatrin escribió:Veo que ya lo tienes cocinado, pero nunca está de más...

Habías visto esta implementación de deflate para 6502?

https://github.com/pfusik/zlib6502

En realidad no está nada cocinado... aún estoy escogiendo los ingredientes para echar a la olla.

No había visto esa implementación... viendo en la descripción:

As the compressed data is read sequentially and only once, it is possible to overlap the compressed and uncompressed data. That is, the data being uncompressed can be stored in place of some compressed data which has been already read.

Es decir, permite hacer lo mismo que mi BINBAK y que la implementaciones de LZ4 para 6502 Atari y Apple, pero mirando el código de Deflate, creo que es demasiado complejo y extenso, pues combina varios algoritmos de compresión.

Hasta el momento, mi elección sigue siendo el LZ4, pero con la variación que en esta oportunidad no haré competir los datos que se obtienen de la descompresión con los que aún están comprimidos en la memoria, sino que los iré sacando desde el cartucho, pero no tengo claro si usaré para ello un buffer ni de qué tamaño. Me habría gustado haber hecho un formato propio como lo había estado pensado, y más adhoc al Atari, pero me parece más útil usar las herramientas existentes y optimizadas para comprimir, y enfocarme sólo en la descompresión en 6502. Si mientras escribo el descompresor cacho que sería bueno, tal vez incluya un filtro entremedio que convierta un bloque ya comprimido en formato LZ4 por otro personalizado.

que grato leer estos temas en retronia....

Un contenedor de LZ4 es demasiado simple, pues sólo tiene la data codificada, pero no existe información adicional como de qué tamaño es el archivo original, así que este formato sirve para hacer algó así como streaming e ir descomprimiendo al vuelo y en tiempo real, ya que los datos ya leídos y utilizados a la primera pueden ser descartados, pues no se volverán a utilizar.

Pero para el caso nuestro, no hay forma de saber cuándo parar de iterar durante la descompresión, por lo que usualmente cuando se trata de archivos de tamaño acotado, se le incorporan 4 bytes al inicio indicando el tamaño original de la data, no el comprimido.

Sin embargo, como a mí me interesa saber además en qué parte de la memoria van a ser descomprimidos los datos, definí mi propio formato al que llamé LZ4X, pero durante la programación me topé con otras restricciones, por lo que hice unos ajustes al formato que especifiqué (en privado), y ya voy en la versión 4. El formato final tiene una cabecera de sólo 2 bytes indicando en qué lugar de la RAM cargar, e incorporé un indicador de fin de datos al final de un bloque LZ4 estándar en lugar del tamaño, repitiendo las veces que sean necesarias para cargar varios bloques en memoria, tal como lo hacen los XEX normales, y finalizando con otro indicador de fin de datos (e iniciar el juego cuando corresponda).

Finalizada la programación del descompresor de acuerdo a este formato, hice una prueba simple usando un pequeño archivo de texto con algunos patrones que permitían al algoritmo LZ4 comprimir usando alternadamente sus 2 métodos (literales y coincidencias). Después reemplacé el archivo de texto por un juego pequeño y tuve éxito: partió a la primera... así que me fui al otro extremo para "sentir" realmente la velocidad de la descompresión. Elegí uno de los juegos que más se comprimió en mi análisis inicial: Boulder Dash... De 216 bloques en DOS (27K), bajó a 102 bloques (13K incluyendo el descompresor), es decir, a poco menos de la mitad. ¿Resultado de la carga? No le tomé el tiempo, pero es lo suficientemente rápida la descompresión. Dejé un ATR en mi sitio: BoulderDash-LZ4X-test.atr. Es un disco con MyDOS y ambas versiones para comparar, idealmente en PC real o emulador sin SIO-Patch... el 1 es el original y el 2 es el comprimido con LZ4.

Ahora a trabajar en la componente del loader usando buffer para obtener la data desde la ROM del cartucho, es decir, comenzaré a trabajar con los BIN o CAR usando la paginación TurboCart.

Buena buena... Sigo muy atento....