Este artículo trata sobre un pequeño programa de MS DOS llamado "Memories". Este programa tiene un tamaño de 256 bytes y ganó el concurso "PC 256 byte" del evento demosceno "Revisión" en 2020, así como el premio de elección del público. Link a un video de la salida de este programa y uno con las reacciones de la audiencia en #1. Este artículo contiene un análisis profundo del programa y los pasos de desarrollo, no sólo para entender el interior de "Memories" sino para aprender como hacer algo por nosotros mismos.
#2:
Tengo un interprete de z-machine en PostScript, y solo el codigo fuente ocupa varios K's. Comprimido ocupa 9k. Algunos juegos para la maquina no bajan de 64 kb, y eso con solo texto.
Alucinante.
En comparacion, existen Unix para microcontroladores con 512kb de RAM, pero ya es mucho mas que esto.
Tambien conozco un cliente Gopher (Gopherus) para MSDOS con un 8088 y menos de 300k de RAM.
#8:
#7 mira el fuente y verás que salvo cambiar el modo de pantalla a 320x200 al principio, no hay nada de BIOS.
#6:
#4 Sí, la BIOS incluye soporte MIDI, un efecto de tablero de ajedrez, otro de círculos concéntricos, otro de laberinto, otro de...
#3:
Con este tipo de demos siempre dudo cuánto de lo que vemos es creado por esos 256 bytes y cuanto es simplemente controlado por esos 256 bytes.
Yo puedo fabricar un dispositivo con arduino que tenga un martillo que reaccione ante una entrada binaria. Con ello podría conseguir romper nueces con un único bit (1 pabajo, 0 parriba). Pero el trabajo lo hace en realidad el arduino, mi código solo le instruye a otro circuito para que haga algo que ya sabe hacer. Y quien dice un rompenueces dice iniciar una guerra termonuclear.
Volviendo al tema no sé cuantos de esos 256 bytes se dedican a crearlo todo desde cero y cuantos simplemente le dan instrucciones a la tarjeta de sonido o tarjeta gráfica a hacer algo que ya saben hacer por sí mismos.
#5:
#3 Mira el fuente comentado y saca tus propias conclusiones.
"En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha mucho tiempo que vivia un hidalgo de los de lanza en astillero, adarga antigua, rocin flaco y galgo corredor. Una olla de algo mas vaca que carnero, salpicon las mas noches, duelos y quebr"
#51 Osti, pues es verdad, es posible que me confundiera, me liara y le diera antes a los enlaces de #1
Pues entonces entono el mea culpa, mis disculpas.
#8 Sobre cosas similares pero no tan enanas (aunque flipante que funcione en la primera CPU de 16 bit de Intel:) http://gopherus.sourceforge.net/.
En cuanto acable el puente Gopher->RSS de Meneame podras leer las noticias y los comentarios (al menos hasta donde de el RSS) incluso en un 8088 con una grafica hercules.
es una demo de mode 13h, lo que se llamaba "vga" de toda la vida de los juegos ms-dos, básicamente usa instrucciones 386 y ese formato gráfico que es muy amigable para hacer hacer "cosas matemáticas", y a día de hoy los pcs lo tienen por retro compatibilidad pero es todo obsoleto.
La originalidad es explotar esas matemáticas para para hacer tanto con tan poco pero obviamente como comenta #3 tiene bios y tiene una estructura propia del procesador y características gráficas. Lo divertido de esto está en que frente a hacer las cosas por exceso de tarjetas gráficas dedicadas y librerías de GL donde sobra la memoria y los recursos, esto es irnos a tecnología de hace mas de 30 años para seguir sacando lo máximo que podamos con el mínimo de espacio. Y en mi opinión es lo que lo que sigue manteniendo ese puntillo geek a la demoscene de PC.
Tengo un interprete de z-machine en PostScript, y solo el codigo fuente ocupa varios K's. Comprimido ocupa 9k. Algunos juegos para la maquina no bajan de 64 kb, y eso con solo texto.
Alucinante.
En comparacion, existen Unix para microcontroladores con 512kb de RAM, pero ya es mucho mas que esto.
Tambien conozco un cliente Gopher (Gopherus) para MSDOS con un 8088 y menos de 300k de RAM.
Con este tipo de demos siempre dudo cuánto de lo que vemos es creado por esos 256 bytes y cuanto es simplemente controlado por esos 256 bytes.
Yo puedo fabricar un dispositivo con arduino que tenga un martillo que reaccione ante una entrada binaria. Con ello podría conseguir romper nueces con un único bit (1 pabajo, 0 parriba). Pero el trabajo lo hace en realidad el arduino, mi código solo le instruye a otro circuito para que haga algo que ya sabe hacer. Y quien dice un rompenueces dice iniciar una guerra termonuclear.
Volviendo al tema no sé cuantos de esos 256 bytes se dedican a crearlo todo desde cero y cuantos simplemente le dan instrucciones a la tarjeta de sonido o tarjeta gráfica a hacer algo que ya saben hacer por sí mismos.
#3: Yo tengo un programa de un bit que reproduce Jumanji a pantalla completa. Si es un 1 se reproduce un DVD que hay en la bandeja con Jumanji, si es un cero no hace nada, saca el DVD porque si no quieres ver la peli, pues eso, guardas el DVD porque si lo dejas por ahí se pierde.
Bromas a parte, creo que a la derecha salen varias categorías para igualar lo que dices, el tipo de entorno donde se ejecutan
#11 Bueno, tecnicamente al reproducir un CD audio de forma analogica hace años el comando era literalmente pasar datos del CD por el BUS a la tarjeta de sonido. En menos de 64 bytes lo haces. Literalmente.
#38 Obviando el hecho de que en MS-DOS no tienes ninguna API gráfica ni de sonido, más que las interrupciones para iniciar y cambiar los modos, todo va bien.
#3 Tarjeta gráfica? Esta Intro es para MS-DOS, y usa el standard VGA clásico de 320x200 dibujando los píxeles a mano uno a uno en la memoria de vídeo en 0xA000.
#48 Es que nunca has compilado PHP con el linkador de Basic? Primero hace un rebase de las tablas de simbolos externos, los contextualiza, luego lo debuga con Python++. Después con SQL le optimiza las llamadas al core, y con Linux le trimea los espacios en blanco para comprimir. Después el USB lo pasa por el baño maría y se emplata.
#49 Yo uso un workflow menos complejo, sólo valgrindeo la raid del intérprete de bytecode java que uso para linkear dinámicamente la vesa en el puerto lpr...
#32 En su momento programé en ensamblador, recuerdo cuando hice mi primer efecto de fuego o de plasma, el subidón que me daba. Ahora es todo PHP y Javascript
Que recuerdos y tiempos cuando vi la demo second reality y flipaba con las que se hacían en esa época, como el programa marte.exe, que ocupaba no se si 4Kb, y te movías por las dunas de marte controlando el vuelo con el ratón en un paisaje que nunca se repetía generado con voxels.... en una época en la que sólo windows y quizás el PCTOOLS soportaba el ratón en PC.
Me acuerdo cuando programaba en ensamblador y tenía que preocuparme de cosas como mover segmentos de memoria a la memoria de video... a partir de ahí, la informática se fue a la mierda.
Es fascinante de lo que se era capaz en la era en la que la memoria y el espacio de almacenamiento valían su peso en oro y había que exprimirlo al máximo.
Lo que a mi mas me sorprende es que hagan un juego tipo clicker (cuatro botones) con unity, que ocupe medio giga y consuma un 50% de la batería, y mas de 700 mb de ram.
#30 El Unity (o el unreal, o el unigine, o el cryengine, o el...) se usan porque facilita mucho hacer juegos. Pero es el equivalente de usar un framework completo de javascript para hacer una web que ponga hola mundo... muchas veces se pueden conseguir resultados incluso mejores haciendo las cosas a pelo o con middlewares más ligeros y simples, pero se usan los gordos porque hay mucha gente formada, dan muchas facilidades y resuelven muchos problemas. Al final, lo que prioriza es que el desarrollo tenga el menor coste posible y cuantas más horas te ahorres en programadores y artistas, mejor.
#44 no lo entiendo yo tampoco, dejo la explicación amplia y oficial del autor incluso con el código y recibo negativos, que asco de usuarios de Menéame, en serio
Programar así hoy en día, sinceramente..., con todo el trabajo dedicado a desarrollar compiladores y evolucionar los lenguajes de programación me parece bastante chorra, bonito para mí es ver un algoritmo bien implementado en Haskell, eso sí da gusto verlo.
Comentarios
Salida:
Audiencia:
Relacionada: "Memories" - intro de 256 bytes (MSDOS)
"Memories" - intro de 256 bytes (MSDOS)
youtube.com#1 Impresionante. Esto son 256 bytes exactamente:
"En un lugar de la Mancha, de cuyo nombre no quiero acordarme, no ha mucho tiempo que vivia un hidalgo de los de lanza en astillero, adarga antigua, rocin flaco y galgo corredor. Una olla de algo mas vaca que carnero, salpicon las mas noches, duelos y quebr"
#51 Osti, pues es verdad, es posible que me confundiera, me liara y le diera antes a los enlaces de #1
Pues entonces entono el mea culpa, mis disculpas.
#51 #52 Pues a mi me pasó igual, fui directo a los links de #1 pero tampoco creo que sea para cascarte negativos. En fin.
#7 mira el fuente y verás que salvo cambiar el modo de pantalla a 320x200 al principio, no hay nada de BIOS.
#8 Sí, lo he visto.
#8 Sobre cosas similares pero no tan enanas (aunque flipante que funcione en la primera CPU de 16 bit de Intel:) http://gopherus.sourceforge.net/.
En cuanto acable el puente Gopher->RSS de Meneame podras leer las noticias y los comentarios (al menos hasta donde de el RSS) incluso en un 8088 con una grafica hercules.
#3 #8 según entiendo yo todos esto...
es una demo de mode 13h, lo que se llamaba "vga" de toda la vida de los juegos ms-dos, básicamente usa instrucciones 386 y ese formato gráfico que es muy amigable para hacer hacer "cosas matemáticas", y a día de hoy los pcs lo tienen por retro compatibilidad pero es todo obsoleto.
La originalidad es explotar esas matemáticas para para hacer tanto con tan poco pero obviamente como comenta #3 tiene bios y tiene una estructura propia del procesador y características gráficas. Lo divertido de esto está en que frente a hacer las cosas por exceso de tarjetas gráficas dedicadas y librerías de GL donde sobra la memoria y los recursos, esto es irnos a tecnología de hace mas de 30 años para seguir sacando lo máximo que podamos con el mínimo de espacio. Y en mi opinión es lo que lo que sigue manteniendo ese puntillo geek a la demoscene de PC.
🌱
Tengo un interprete de z-machine en PostScript, y solo el codigo fuente ocupa varios K's. Comprimido ocupa 9k. Algunos juegos para la maquina no bajan de 64 kb, y eso con solo texto.
Alucinante.
En comparacion, existen Unix para microcontroladores con 512kb de RAM, pero ya es mucho mas que esto.
Tambien conozco un cliente Gopher (Gopherus) para MSDOS con un 8088 y menos de 300k de RAM.
#4 Sí, la BIOS incluye soporte MIDI, un efecto de tablero de ajedrez, otro de círculos concéntricos, otro de laberinto, otro de...
#6 No, pero proporciona una API para muchas cosas, y maneja el acceso a hardware.
Con este tipo de demos siempre dudo cuánto de lo que vemos es creado por esos 256 bytes y cuanto es simplemente controlado por esos 256 bytes.
Yo puedo fabricar un dispositivo con arduino que tenga un martillo que reaccione ante una entrada binaria. Con ello podría conseguir romper nueces con un único bit (1 pabajo, 0 parriba). Pero el trabajo lo hace en realidad el arduino, mi código solo le instruye a otro circuito para que haga algo que ya sabe hacer. Y quien dice un rompenueces dice iniciar una guerra termonuclear.
Volviendo al tema no sé cuantos de esos 256 bytes se dedican a crearlo todo desde cero y cuantos simplemente le dan instrucciones a la tarjeta de sonido o tarjeta gráfica a hacer algo que ya saben hacer por sí mismos.
#3 En DOS la BIOS hace todo en realidad.
#3 Mira el fuente comentado y saca tus propias conclusiones.
#3: Yo tengo un programa de un bit que reproduce Jumanji a pantalla completa. Si es un 1 se reproduce un DVD que hay en la bandeja con Jumanji, si es un cero no hace nada, saca el DVD porque si no quieres ver la peli, pues eso, guardas el DVD porque si lo dejas por ahí se pierde.
Bromas a parte, creo que a la derecha salen varias categorías para igualar lo que dices, el tipo de entorno donde se ejecutan
#11 Bueno, tecnicamente al reproducir un CD audio de forma analogica hace años el comando era literalmente pasar datos del CD por el BUS a la tarjeta de sonido. En menos de 64 bytes lo haces. Literalmente.
#36: Efectivamente, el CD es parte de la API, así que tienes sonido completo en menos de 64 bytes.
#38 Obviando el hecho de que en MS-DOS no tienes ninguna API gráfica ni de sonido, más que las interrupciones para iniciar y cambiar los modos, todo va bien.
#3 es lo que hace el software: instruir a un circuito para que haga algo que ya sabe hacer.
#3 no lo había visto de esa manera. Gracias por el enfoque.
#3 Tarjeta gráfica? Esta Intro es para MS-DOS, y usa el standard VGA clásico de 320x200 dibujando los píxeles a mano uno a uno en la memoria de vídeo en 0xA000.
No, la demo no controla, crea todo lo que ves.
Aprovecho para recordar al respetable el clásico entre los clásicos de las demos:
Second Reality by Future Crew
#18 que mítica... y que mal de lleva con la compresión de vídeo de YouTube
#27 Cierto, hay otras que no contienen ruido, pero se saltan la parte inicial que se ven las estrellas y eso es pecado.
Yo me he mirado el código y le sobran 72 bytes.
#13 ¿El fuente o el compilado?
#39 Está escrito en PHP,asi que no hay diferencia.
#47 ¿Un ejecutable .com escrito en php?
Me da que estamos hablando de cosas distintas...
#48 Es que nunca has compilado PHP con el linkador de Basic? Primero hace un rebase de las tablas de simbolos externos, los contextualiza, luego lo debuga con Python++. Después con SQL le optimiza las llamadas al core, y con Linux le trimea los espacios en blanco para comprimir. Después el USB lo pasa por el baño maría y se emplata.
#49 Yo uso un workflow menos complejo, sólo valgrindeo la raid del intérprete de bytecode java que uso para linkear dinámicamente la vesa en el puerto lpr...
Se que es antigua (2009) pero esta demo de 4kb siempre me encanto:
Alucinante.
Ahora explicadme por qué un puto driver ocupa 500 megas.
#16 Porque no es el driver, si no la mierda suite de herramientas.
#32 En su momento programé en ensamblador, recuerdo cuando hice mi primer efecto de fuego o de plasma, el subidón que me daba. Ahora es todo PHP y Javascript
64k deberían ser suficientes para cualquier programa.
#14 y lo son. Esto son 256 bytes, No 256 kB
#41 Sabía que entenderías la referencia.
Me acabo de acordar cuando programaba porque me gustaba
#19 No se pero yo dedico muchas horas a programar y viendo esto pienso; "que ganas de perder el tiempo..."
Que recuerdos y tiempos cuando vi la demo second reality y flipaba con las que se hacían en esa época, como el programa marte.exe, que ocupaba no se si 4Kb, y te movías por las dunas de marte controlando el vuelo con el ratón en un paisaje que nunca se repetía generado con voxels.... en una época en la que sólo windows y quizás el PCTOOLS soportaba el ratón en PC.
Me acuerdo cuando programaba en ensamblador y tenía que preocuparme de cosas como mover segmentos de memoria a la memoria de video... a partir de ahí, la informática se fue a la mierda.
Es fascinante de lo que se era capaz en la era en la que la memoria y el espacio de almacenamiento valían su peso en oro y había que exprimirlo al máximo.
Lo que a mi mas me sorprende es que hagan un juego tipo clicker (cuatro botones) con unity, que ocupe medio giga y consuma un 50% de la batería, y mas de 700 mb de ram.
Eso si es difícil.
#30 El Unity (o el unreal, o el unigine, o el cryengine, o el...) se usan porque facilita mucho hacer juegos. Pero es el equivalente de usar un framework completo de javascript para hacer una web que ponga hola mundo... muchas veces se pueden conseguir resultados incluso mejores haciendo las cosas a pelo o con middlewares más ligeros y simples, pero se usan los gordos porque hay mucha gente formada, dan muchas facilidades y resuelven muchos problemas. Al final, lo que prioriza es que el desarrollo tenga el menor coste posible y cuantas más horas te ahorres en programadores y artistas, mejor.
Por si queréis ver el código y explicaciones de cómo hizo cada efecto http://www.sizecoding.org/wiki/Memories
#29 Quiero pensar que te han votado negativo por error.
#44 no lo entiendo yo tampoco, dejo la explicación amplia y oficial del autor incluso con el código y recibo negativos, que asco de usuarios de Menéame, en serio
#45 quizás sea porque el link que has puesto es el mismo que el de la noticia
CC #44
¿Demobsceno?
gopher://1/meneame
Funcionaría con Gopherus en la chatarra del PC de #0.
De momento solo links html, pero en el futuro pienso poner un extracto del texto mediante links -dump.
Vengo a dejar esto y ya me voy:
No le quito mérito, que tiene muchisimo, pero no entiendo el hype, me esperaba algo más emocionante o emocional....
(MODO DESDE LA BARRA DE BAR/CUÑAO)
Eso lo hago yo mejor...
Manolo, sujétame el cubata y tráeme un boli y una servilleta...
#22 puff cuántas servilletas gaste en eso cuando tiraba de ensamblador
Programar así hoy en día, sinceramente..., con todo el trabajo dedicado a desarrollar compiladores y evolucionar los lenguajes de programación me parece bastante chorra, bonito para mí es ver un algoritmo bien implementado en Haskell, eso sí da gusto verlo.
#33
> un algoritmo bien implementado en Haskell
Pajillero detected.