Hola,
1) Descompresores JPG, Conexiones a internet :
El problema de esto es que no se tiene informacion exacta de como se
comprime/descomprime JPG,
http://www.cica.indiana.edu/graphics/image_specs/jpeg.format.txt <- JPEG
File Interchange Format, Version 1.02 (.txt)
http://www.w3.org/Graphics/JPEG/jfif3.pdf <- JPEG File Interchange Format,
Version 1.02 (PDF, 9 páginas)
http://www.w3.org/Graphics/JPEG/itu-t81.pdf <- CCITT Recommendation T.81:
Information Technology Digital Compression And Coding Of Continuous-tone
Still Images - Requirements And Guidelines (PDF, 186 páginas)
Los dos primeros documentos son básicamente el mismo, sólo cambia el
formato. Por lo poco que los he mirado, describen la estructura de un
fichero JFIF/JPEG. El tercer documento es bastante más extenso (y complejo)
y se mete de lleno en algoritmos.
Tal vez con lo de "no se tiene información exacta" te referías a "no sé
buscarla" o "no la entiendo".
comprime/descomprime JPG, o de la implementacion completa del TCP/IP de
internet. Hay mucha informacion, pero incompleta.
ftp://ftp.rediris.es/pub/docs/rfc/7xx/768 <- User Datagram Protocol (UDP)
(.txt)
ftp://ftp.rediris.es/pub/docs/rfc/7xx/791 <- Internet Protocol (IP). DARPA
Internet Program - Protocol Specification (.txt)
ftp://ftp.rediris.es/pub/docs/rfc/7xx/792 <- Internet Control Message
Protocol (ICMP). DARPA Internet Program - Protocol Specification (.txt)
ftp://ftp.rediris.es/pub/docs/rfc/7xx/793 <- Transmission Control Protocol
(TCP). DARPA Internet Program - Protocol Specification (.txt)
ftp://ftp.rediris.es/pub/docs/rfc/8xx/815 <- IP Datagram Reassembly
Algorithms (.txt)
ftp://ftp.rediris.es/pub/docs/rfc/8xx/821 <- Simple Mail Transfer Protocol
(SMTP) (.txt)
ftp://ftp.rediris.es/pub/docs/rfc/8xx/854 <- Telnet Protocol Specification
(.txt)
ftp://ftp.rediris.es/pub/docs/rfc/9xx/959 <- File Transfer Protocol (FTP)
(.txt)
ftp://ftp.rediris.es/pub/docs/rfc/16xx/1661 <- The Point-to-Point Protocol
(PPP) (.txt)
A qué te referías con lo de "incompleta"?
Para descubrir todo esto, hay que pasar varios años, sin hacer otra cosa.
Hombre, hay otros métodos más rápidos: te vas a un buscador, escribes lo que
necesitas y le das al botón de 'search'. Es lo que he hecho yo con lo de las
especificaciones del JPEG, que no las había necesitado en mi vida. Tiempo:
unos 5 minutos (5 minutos < varios años).
Hacer programas de correo, navegadores, FTP es facil, si se tuviese el
programa de conexion/transmision basico. Pero no lo tenemos.
Lo tenemos. UZIX.
Los formatos del MIF parecen estupendos, y muy apropiados para MSX.
MIF no es standard. Si JPEG no es adecuado, se busca una solución standard
que sí que lo sea. Por ejemplo, PNG (ve a www.google.com y en la search
string pones 'PNG specification', a ver lo que tardas en encontrar la
documentación). No creo que sea necesario reinventar la rueda si ya la
tenemos ahí.
Personalmente, tardo menos en hacer las cosas para MSX en ensamblador, que
en C para PC.
Yo también tardo menos en comerme una aceituna que una sandía. Así de
parecidos son assembler y C. Si compararas programar en C para MSX con
programar en C para PC, verías que te saldrían tiempos muy parecidos, igual
que en assembler para MSX y para PC.
Y si tuviese que elegir un lenguaje ideal para programar para MSX (puesto
que ni el Basic ni el ensamblador lo son)
nunca elegiria el C, ni ninguno otro de los que hay para PC y similares.
Diseñaria un lenguaje a medida del MSX y de sus usuarios: facil, sencillo,
rapido, sin limitaciones, con acceso a todo el hardware MSX, etc.
Y yo desarrollaría una vacuna contra el SIDA, diseñaría un aparato que
terminara con el armamento mundial y con el hambre del tercer mundo y la
pobreza. Pero no soy Dios (todavía). Así que tendré que poner los pies en el
suelo y adaptarme a lo que hay (C) en vez de intentar cambiar el mundo.
Francamente, mi visión de la situación es la siguiente:
- El MSX está muriendo porque no se desarrolla software nuevo. Me refiero a
software útil. Aplicaciones.
- Cada día salen cientos de aplicaciones nuevas para UNIX.
- El software de UNIX se compila de forma transparente entre plataformas,
gracias a un compilador C standard (egcs/gcc).
Solución al problema: un UNIX para MSX (los de UZIX ya están en ello, y van
por muy buen camino), y un compilador de C con sus librerías para MSX. De
esta forma, el poco software que no compilara directamente se podría portar
en muy poco tiempo. ¿Para qué intentar desarrollar nosotros el software, si
ya hay gente haciéndolo a diario?
Ok, las aplicaciones correrían más deprisa si estuvieran escritas en
assembler. Pero francamente, la productividad en este caso es más importante
que el rendimiento. Prefiero tener una aplicación en C que funcione un poco
más lenta que si estuviera escrita en ASM a no tenerla. Ah, por cierto,
prácticamente todo el software de ASCII para MSX está escrito en C.
El problema que veo en estos momentos con el MSX es que los cuatro gatos que
saben assembler se pasan el día hablando de cosas de las que no tienen ni
idea, en vez de ponerse a aprender cosas nuevas. Son considerados gurús y
todo el mundo toman lo que dicen como palabras divinas. Y todos siguen
ignorando el mundo que les rodea. De la scene española, el único que conozco
que se salva de la quema (ojo, no estoy diciendo que sea el único), sería
Nestor.
Francamente, llevo unos cuantos añitos ya con UNIX (Linux, Solaris y
FreeBSD), y sé que aquí hay bastante material como para volver a sacar al
MSX a flote. No de forma comercial, por supuesto, pero sí de forma que un
usuario de MSX pueda estar tranquilamente conectado a Internet con su
máquina, sin que nadie le tenga que mirar por encima del hombro.
Saludos,
Javi Lavandeira
Director Tecnico
Inlander Communications, S.L.
Tel: (+34) 93 310 12 86 Fax: (+34) 93 268 14 79
javilm(_en_)inlander(_punto_)es - http://www.inlander.es
----- Original Message -----
From: Daniel Zorita <dzorita(_en_)teleline(_punto_)es>
To: HispaMSX <hispamsx(_en_)onelist(_punto_)com>
Sent: Monday, March 13, 2000 3:01 PM
Subject: [hispamsx] Propuestas sobre el Z380.
From: "Daniel Zorita" <dzorita(_en_)teleline(_punto_)es>
Va, 13 Marzo 2000
Hola.
Gracias a los que han mostrado interes y preocupacion por el tema del
Z380.
Primero, respondo a las diversas ideas propuestas:
1) Descompresores JPG, Conexiones a internet :
El problema de esto es que no se tiene informacion exacta de como se
comprime/descomprime JPG, o de la implementacion completa del TCP/IP de
internet. Hay mucha informacion, pero incompleta.
Para descubrir todo esto, hay que pasar varios años, sin hacer otra cosa.
Hacer programas de correo, navegadores, FTP es facil, si se tuviese el
programa de conexion/transmision basico. Pero no lo tenemos.
Asi que "animad" o "meted prisa" a quienes esten metidos en el tema.
El JPG: Buscad a quienes hicieron los descompresores JPG para MSX, y que
nos
pasen el codigo fuente, o la informacion de los algoritmos, para que
podamos
adaptarlos al Z380.
Pero recordad que el JPG no es un buen formato para MSX, porque se notan
mucho los "cuadraditos", y el MSX no tiene tantos colores como para
disimular los defectos de la imagen.
Los formatos del MIF parecen estupendos, y muy apropiados para MSX. Habria
que hablar con los autores, para que versionasen esas utilidades para
Z380.
2) Compiladores de C para MSX :
Tanto los quereis? Pues ya os dije, que primero hicieseis pruebas con los
compiladores de C para Z80 / Z380, bajo PC, y ejecutando el resultado en
MSX.
Si funciona, y si va rapido, y si es util, pues ya estudiariamos el hacer
compiladores de C para MSX
Pero si no funciona bien, es engorroso, o encima va lento, pues mejor nos
ahorramos 2 años de desarrollo del compilador, y hacemos otras cosas mas
interesantes.
Personalmente, tardo menos en hacer las cosas para MSX en ensamblador, que
en C para PC.
Son muchos años de "practica"
Y si tuviese que elegir un lenguaje ideal para programar para MSX (puesto
que ni el Basic ni el ensamblador lo son)
nunca elegiria el C, ni ninguno otro de los que hay para PC y similares.
Diseñaria un lenguaje a medida del MSX y de sus usuarios: facil, sencillo,
rapido, sin limitaciones, con acceso a todo el hardware MSX, etc.
Si lo que quereis es hacer un compilador de C para MSX para poder compilar
los protocolos de internet, pues para eso se puede usar el compilador de C
para Z80 / Z380 bajo PC, o no ?
Pues ya esta, para que complicarnos?
Si la mitad de nosotros ya tenemos un PC, pues probemos esas utilidades de
Z80 / Z380
3) Sobre emuladores de Z80, u otras maquinas:
Pues seria lo mismo que hacer un emulador de XXX para PC.
Llevaria mucho trabajo, y a lo peor, queda lento.
Es necesario?
De acuerdo que seria curioso, y tal. Pero necesario ?
En la cuarta parte de tiempo en que se hace un emulador, se puede hacer un
editor multiventana, y un sistema multitarea MSX.
Y para trastear con un juego MSX, no hace falta un emulador. Bastaria con
modificar las interrupciones ( o parchear el programa un poco) para poder
interrumpirlo y examinar la memoria, pantalla, etc.
Teniendo suficiente RAM en el MSX, no haria falta nada mas.
4) Utilidades de disco:
Esto ya me parece mas interesante.
Sobre todo a raiz de que tengo pendiente lo del "CANOROS", que era una
especie de "multiescritorio", al estilo del Guindos de PC, pero quitando
la
"roña" y defectos, y haciendolo a medida de MSX.
Sobre lo de la FAT de 16 bits, etc, creo que la solucion es esta:
a) No modificar el MSX DOS 2, para que sigamos teniendo compatibilidad.
b) Hacer utilidades que accedan a varias particiones de disco duro, pero
mostrandolas unidas. Es decir, de manera "virtual" tendriamos un disco de
p.e: 1 GB.
El sistema, distribuye los ficheros entre las diferentes particiones que
tengamos autorizadas para ello.
Bajo MSX DOS, tendriamos particiones de 32 MB,
pero bajo el "administrador de ficheros", tendriamos todas juntas en una.
c) No se podrian grabar ficheros de mas de 32 MB, salvo que se dividiesen
en
trozos mas pequeños.
d) Se puede aprovechar mas cada cluster de 8KB : Almacenar los ficheros
dentro de otro mayor (que haria de contenedor, o pseudo-directorio) y asi
no
se desaprovecha el espacio de disco cuando tenemos muchos ficheros
pequeños.
Ademas se podria poner con la opcion de "compresion automatica" de
ficheros,
en ciertos directorios.
e) Habria que suministrar unas rutinas para acceder a los ficheros segun
este sistema. Asi el programador, se olvidaria de las particiones.
Ademas se pueden hacer rutinas para "abrir" "guardar-Como" al estilo de
PC.
Una especie de "explorador de ficheros", que fuese llamado por cada
programa.
f) Todo esto, con 2 versiones: una para MSX, y otra para MSX+Z380 (que
seria mas rapida, claro)
Os parece ?
Bueno, seguid pensando mientras nosotros seguimos haciendo las primeras
aplicaciones basicas del Z380.
Ninguna sugerencia para juegos Z380 ???
Chao.
Daniel Zorita, dzorita(_en_)teleline(_punto_)es
------------------------------------------------------------------------
MAXIMIZE YOUR CARD, MINIMIZE YOUR RATE!
Get a NextCard Visa, in 30 seconds! Get rates as low as
0.0% Intro or 9.9% Fixed APR and no hidden fees.
Apply NOW!
http://click.egroups.com/1/2122/0/_/666427/_/952955824/
------------------------------------------------------------------------
*HispaMSX. La mailing-list de MSX en castellano*
Para cualquier duda: msxjam(_en_)crosswinds(_punto_)net
