CURIOSIDAD: Forzando rutinas de carga

[zup]

En sus días, los desarrolladores se ocuparon de abusar convenientemente de las rutinas de carga. Turbos, datos cargados en desorden, tonos guía casi inexistentes... un poco de todo. También hubo programas que se cargaban encriptados y al acabar la carga se desencriptaban, o juegos que cargaban datos comprimidos y luego los descomprimían. Esto pasaba en los ZX Spectrum, y supongo que en MSX y CPC pasaría lo mismo.

La pregunta es... dado que la mayoría de los algoritmos de descompresión pueden funcionar en stream, ¿hubo alguna rutina de carga que descomprimiera datos "al vuelo" mientras cargaba? ¿Habría suficiente CPU para permitirlo?

La ventaja es que no se necesitaría tanta memoria (no necesitas tener los datos cargados antes de descomprimir) y si lo juntas con una carga turbo (si hay tanta CPU), obtienes una preciosidad que reduce mucho el tiempo de carga.

En cierto juego llegué a sospechar que lo hacían, pero luego lo descarte (a veces veo cosas donde no las hay, y no soy TAN experto depurando). ¿Se hizo esto alguna vez?

[Namek]

Yo creo recordar una rutina de carga que se saltaba los ceros, osea, que cuando venian series grandes de bytes a 0 no las cargaba, sino que saltaba al siguiente dato que no era 0, esto lo vi en una pantalla de carga, pero no recuerdo de que juego.

En cuanto a lo de descomprimir mientras se carga lo veo mas una chulada que algo realmente util, ya que los descompresores actuales como exomizer por ejemplo descomprimen bastante rapido como para no necesitar hacerlo a la vez que la carga y si encima usas cargadores ultra-turbos como K7ZX, OTLA o CARGANDOLECHES tiene aun menos sentido.

Un saludito...

[scooter]

Para C64 recuerdo haber usado una rutina de compresión para gráficos; enviaba el byte y el número de veces que se repetía. Si la pantalla estaba mas bien en blanco era eficiente, si estaba mas bien llena era una M tremenda.

[robcfg]

Lo que comentas es un algoritmo RLE (Run Length Encoding) y como bien dices, si tienes areas grandes del mismo color, funciona aceptablemente bien, y si no, ocupa más que el original.

[BlackHole]

Un algoritmo RLE es posible que sí pueda darse, pero compresores serios como los actuales basados en Lempel-Ziv te aseguro que no da tiempo a cargarlos desde una cinta secuencial al vuelo, porque he probado y no hay ciclos. Tras finalizar la carga sí, son bastantes las cosas que he hecho con aPLib y descomprimen tras la carga a 35 KB/s (incluso a 50 KB/s si me molesto en usar una rutina descompresora más larga con todos los bucles completamente desenrollados) con lo que la experiencia de usuario no se ve mermada en absoluto.

En su día, cuando utilizabamos descompresores al vuelo fue en la escena del C64, para los juegos con múltiples fases, ya que la carga desde disquetera con acceso aleatorio era completamente asíncrona. No tenías que preocuparte en medir en absoluto los tiempos fijos de un bit como sucede en la cinta magnética secuencial, simplemente le pedías al dispositivo un byte, y cuando lo obtenías ibas a por el siguiente. Si la petición se hacía en medio de una rutina de descompresión, pues igual que si lo leyeses de memoria directamente solo que tardaría algo más en volver de una hipotética subrutina "OBTENER NUEVO BYTE", era transparente en ese sentido. Luego en la disquetera del C64, al ser inteligente y llevar ROM y RAM propia, podías tener una carga turbo que proporcionase en el bus serie los bits más rápido, pero de nuevo, completamente transparente en el extremo remoto: tú pedías cargar un byte, y al ser asíncrono, podrías tener una rutina de muy bajo nivel que se encargase de toda la entrada/salida, que lo que había por encima seguía siendo compatible.

Pero bueno, el mismo proceso también se da en la escena rusa del Spectrum y su ubícuo TR-DOS para carga de disco, aunque en ese caso, el compresor por excelencia siempre fue el HRUST.

[zup]

Vale, era un tema de curiosidad.

La ventaja de este sistema es que no necesitas (casi) memoria RAM. En los compresores tradicionales tienes que tener por un lado los datos comprimidos y por otro suficiente espacio para descomprimir sin cargarte los que estás descomprimiendo en ese momento (podrías cargarte datos que ya hubieras descomprimido), con este sistema los datos comprimidos los vas leyendo de cinta y no ocupan lugar en la memoria.

Ahora bien, si no hay ciclos se acabó el invento. A menos que inventes una rutina de carga más lenta... lo que acaba con la ventaja de comprimir los datos.

[Namek]

La mayoria de descompresores actuales para Spectrum funcionan machacando sobre los datos comprimidos que ya has descomprimido, de lo contrario seria imposible descomprimir bloques de 41K, por ejemplo el FILE COMPRESSOR que he usado bastante solo necesita los 150 bytes extra que ocupa la rutina descompresora, por tanto en un Spcetrum de 48K podrias descomprimir un bloque de casi 48K menos esos 150 bytes y lo que haga falta de STACK... Con estas cosas yo ALUCINO!!!

[BlackHole]

Yo me hice, ya hace muchos años, de cuando preparé el paquete del Cannon Bubble, un programa en C que apoyándose sobre la librería de aPLib, iba calculando el número máximo de bytes que necesitábamos "salvar" para prevenir el solapamiento. En ese caso fueron 4 bytes solamente, aunque lo normal es que solo sean 2 ó 3, salvo que haya zonas previas no compresibles. Hay que evitar comprimir lo ya comprimido.

Ahí donde lo veis, el Cannon Bubble cuya carga es un bloque de 68 KB, en realidad luego son unos 140 KB que se van utilizando cuando toca.