El 386 fue un éxito de ventas incluso antes de que apareciera el software que exprimiera todo su potencial. ¿Era sólo hype o realmente supuso un cambio revolucionario? Curiosamente, IBM no fue el primero en participar en la generación de 32 bits del PC que él mismo había inventado, sino que Compaq y Zenith tomaron la delantera.
|
etiquetas: 386 , 1986 , pc , 32 bits , the computer chronicles
Llegué a montar un windows 95 en 386DX sin coprocesador, usando una soundblaster isa que tenía un ide incorporado. Le enchufé el cdrom ahí. Oye y caminaba. Creo recordar que llevaba 4mb de ram y un disco de 40Mb. Aunque lo del disco no recuerdo si llegué a tocarlo. Por casa de mi abuela, en el sotano debe andar cogiendo polvo. Si algún dia vuelo a Barcelona y funciona igual hasta hago un video.
Era el segundo ordenador que entró en casa. El primero un Amstrad pc1512 de 512kb de memoria, cga y doble floppy. 8086... tiempos de clones de juegos de spectrum y cia... goody, zaxxon, top, ibm cat, the last mission, mach3 (con sample inicial molon) , maniac masion, the monkey island...
Luego entró ese 386dx... y estrujado quedó que el siguiente fué un pentium 2 mmx con vodoo guillemot adosado a una virge s3. En 386... tiempos de pcfutbol, wolfenstein, doom, gods, sim cities, dune 2, monkey island 2, indinana johnes -atlantis y last crusade- vikings, the chaos engine, louts, 4d racing, stunt island, apache pff tantos...
Y todos estos recuerdos se perderán como lágrimas en la llúvia.
Off-Topic: Supongo que conoces el documental de la Programma 101, cuando Olivetti inventaba cosas "radicales".
Por si a alguien le interesan esas cosas: www.youtube.com/watch?v=HkI04PkTZTc
Edit: Syntax error - corregido
- En 1986 fue cuando empecé yo a estudiar informática así que más o menos tengo la época ubicada.
- Un PC normalito (clónico) no bajaba de 200.000 pesetas. Un IBM XT se podía ir fácil a 300.000 (se lo pilló un compañero de la uni)
- El 386 estaba ... pero inalcanzable (total, salvo que le metieras un UNIX o XENIX) solo había MSDOS. A mí, con el que me caía la baba era con el 68030 (hoy en día tengo uno en mi colección de CPUs)
- La gama alta eran los IBM AT (80286) que creo andaban por medio millón de pelas (un sueldo majete de la época sería 120.000)
- AMSTRAD rompió la baraja sacando el 1512 por 150.000 pelas. Encima te regalaba un impresora que contribuyó a dejar sorda a la mitad de mi generación. Un paquete similar de cualquier otro se te podía ir a 600.000 pesetas (ojo, con disco duro que el 1512 barato no tenía)
- En 1990 empecé a currar y en la oficina se había gastado como 1,25 millones de pesetas en un 486 a 25 Mhz con el que usando XENIX trabajábamos a la vez hasta 6-8 personas. Creo que tenía como 12 MB de RAM (sí, MB) y un disco duro de unos 200 MB. Era Olivetti. Tenía una placa multipuerto RS-232 que costaba una pasta para conectar creo que hasta 8 terminales RS-232, luego aparte estaba la consola y el puerto serie de la máquina (o dos, no me acuerdo)
- Los discos duros por mi época habían bajado bastante de precio, unas 60.000 pesetas 30 MB. He trabajado con algunos equipos de años anteriores que me dijeron que el precio del HD había llegado a costar como un millón de pesetas (10-20 MB como mucho)
- Los modem solo los llegamos a usar para pruebas. Era más rápido y barato mandar a un mono con una caja de diskettes a actualizar el SW (nos movíamos sobre todo por la zona centro de Asturias)
Edit: Ah! y un disco ESDI de 80Mb
Valían un pastón, pero con uno llevabas una oficina mediana.
es.wikipedia.org/wiki/Microsoft_XENIX
Ten en cuenta que Bill Gates trabajaba en PDP/11, PDP/10 y cosas así antes de todas las porquerías (por ejemplo el BASIC de Altair se escribió en un PDP/10), así que le gustaba lo *X
es.wikipedia.org/wiki/Altair_BASIC
Creo que te confundes con el 8087, que era el coprocesador matemático para el 8086 (y no sé si también servía para el 8088).
Trabajábamos con Olivetti que, en su momento, era como la segunda de Europa en informática, el estándar del M386 de gama alta, un pedazo de torre, era el de 135Mb, creo que costaba un millón sin placa multipuerto, pero el de 300 costaba un disparate.
Te pongo una foto del bicho
Se podría juntar con Bill Gates que dijo que nadie iba a necesitar más de 640Kb de RAM.
Al final lo que menos costaba era el pc, la tarjeta multipuertos valía una pasta y recuerdo haber vendido uno con un disco de 300Mb y asegurar la operación con Crédito y Caución porque en caso de impago hubiésemos ido a la ruina.
Lo de reiniciar o que se bloqueasen siempre o casi siempre era por algo de hard, eso iba como un tiro.
Yo cuando entré programaba el M50 o Sistema 6000 que tenia ambos nombres, un bicho como los de las películas, con montones de teclas y luces y en una habitación refrigerada y con filtros de aire, costaba lo mismo que un piso de lujo en la costa, como 5/6 kilos del 84, lo sé porque antes trabajaba en una inmobiliaria
Cuando aterrizaba un disco "removible", no costaba menos de medio kilo arreglarlo.
Que tiempos. Aunque era un chaval, el hecho de tocar un chisme tan caro hacía que me pusieran la alfombra roja
Del M24 me acuerdo bien, se vendió mucho, cuando salieron los PC ya se nos acabó la época de la alfombra roja
Mira la tabla en Chronology en.m.wikipedia.org/wiki/X86
El coprocesador matemático del 486 era muy preciso pero extremadamente lento.
En esa época cuando necesitaba calcular trigonometria para demoscene utilizaba tablas de enteros precalculadas y ni me acercaba al copro.
Venía con una caja enorme llena de manuales
Además muchos tuvimos nuestro 386 cuando ya se vendían "clónicos" a troche y moche por que los "de marca" seguían siendo carísimos.
Es decir, en lugar de ejecutar una instrucción a la vez, como los anteriores procesadores hacían, el Pentium podía ejecutar múltiples instrucciones a la vez en paralelo. Antes de eso, era habitual hablar de "ciclos por instrucción" para referirse a la velocidad de una CPU. Pero a partir del Pentium, se pasó a hablar de "instrucciones por ciclo", puesto que en un mismo ciclo de reloj, la CPU podía ejecutar multiples instrucciones.
Recordemos, todo esto con un solo "core".
Es decir, en vez de ejecutar sin(90) por software o por coprocesador, símplemente accedes a array_sin[90], que tarda nada.
Se pierde precisión, pero se gana una barbaridad en velocidad. Y la precisión a veces no es tan importante, especialmente a las resoluciones gráficas que se usaban en aquella época.
Yo he visto uno y por detrás solo tienen puentes o jumpers, no es un lector de velocidad real.
Del año siguiente. Empezamos el curso sin un puto ordenador (aparte del spectrum de mi casa) y a mediados de curso consiguieron tres IBM PC para todos (yo creo que Wenceslao, el que luego sería alcalde se Oviedo y que de aquella daba clase en Uniovi y trabajaba en IBM debió de tener algo que ver)
Y lo del CPD para COBOL, tal cual.
Así acabé programando sistemas embedidos -era pre android/ios, pues ya arm existía... jtags...uclinux sin gestor de memoria- hasta que la vida me llevo a la tranquilidad del devops, la nube y esas movidas... que dan de comer, amplian el horizonte pero ni son tan complejos ni motivan tanto. Igual también es que uno se hace mayor. En fin.
Gracias x tu repsuesta
He jugado cientos de veces y nunca vi esa opción, tampoco he encontrado nada en internet que confirme lo que dices.
Sin embargo, Doom no podía usar el coprocesador matemático, ya que estaba diseñado para funcionar en procesadores 486 o superiores, que ya tenían el coprocesador integrado.
Esta frase parece contradictoria, que el procesador vaya en un chip a parte o integrado es indiferente para el software.
Cuando compilas el código puedes optar a que use instrucciones de coma flotante para el procesador o el coprocesador, si optas por el coprocesador sólo funcionará si existe , da igual si de forma independiente como el i387 o el integrado en los 486DX
Si el procesador detecta que cierta instrucción B necesita el resultado de la anterior instrucción A, entonces lo que hace es meter instrucciones posteriores o anteriores C, D, E, que no necesitan de ese resultado y las ejecuta antes que B. Por ejemplo, si el programa originalmente era
A
B (depende de A)
C (no depende de A ni B)
D (no depende de A ni B)
E (no depende de A ni B)
el procesador las reordena "al vuelo" en algo como A, C, D, E, B.
Básicamente, mientras que espera a que termine A, adelanta trabajo que tiene que hacer después, y luego sigue con B, y ese trabajo que ha adelantado ya no tiene que hacerlo.
El código CISC del programa se traducen en microcódigo RISC que es lo que realmente se ejecuta.
El programador tiene la certeza de que, haga lo que haga la CPU, el resultado del programa es idéntico, porque se garantiza la coherencia del mismo. Cuando se reordenan instrucciones, como las instrucciones que cambian de posición no usan resultados de las anteriores, el cálculo final es el mismo.
En situaciones donde el programador pudiera confundirse, como por ejemplo, al ejecutar un depurador paso por paso, toda esta reordenación y tal es desactivada.
En RISC, todas las instrucciones duran exactamente lo mismo porque son sencillísimas: obtener instrucción, obtener valor que opera, hacer operación (suma, resta, comparación, cosas muy simples), almacenar el resultado.
La instrucción CISC de búsqueda de un valor en un array se traduciría por tropecientas instrucciones RISC.
El quid es que ejecutar instrucciones RISC nos permite hacer todos estos trucos de reordenar instrucciones, tener multiple pipelines, etc, con lo que merece la pena el esfuerzo de diseñar todo eso.
Y, en fin, el tiempo les dio la razón.
La S3 Virge era una tarjeta PCI y ese bus se creó para los Pentium aunque también se usaron en los 486 más modernos, pero jamás para los 386.
me acuerdo de todas las especificaciones de mi máquina.
yo creo que no
en.wikipedia.org/wiki/S3_ViRGE
es.wikipedia.org/wiki/Peripheral_Component_Interconnect
De lo que si las CPUs tardan lo mismo en ejecutar cada instrucción pues no lo sé, pero en procesadores como el z80 no, cada instrucción utilizaba distinto número de ciclos de cpu, incluso recuerdo que ciertas instrucciones requerían una barbaridad de ciclos y se procuraba no usarlas nunca.
Luego añade que la versión del Win95 era la OSR2, que ya venía con el iExplore, soporte para USB, AGP, FAT32 y demás, y lo mejor de todo era que el ordenador no tenía CD-ROM , con 15-16 años, a mediados de los 90, no me podía gastar casi 20.000 Ptas. en un CDROM.
Así que adivina como instalé el Win95..., 26 maravillosos disketes de 1.68Kb que me dejaron copiar en el instituto. 3 horitas y algo duraba de media la instalación.
La secuencia de la disquetera durante la instalación era maravillosa, se encendía el LED verde, leia un par de pistas, si había suerte quizá leía una tercera pista, "clac - clac", se apagaba el LED, entre 8 y 10 segundos de silencio mientras el ordenador descomprimía y almacenaba en la memoria las dos pistas que acababa de leer, se vuelve a encender el LED, lee otras dos pistas, "clac - clac", se apaga el LED, otros 8-10 segundos de silencio y así con los 26 disketes...
Cabe señalar que el programa de instalación no descomprimía los .CAB directamente en el disco duro sino en la memoria RAM, una vez llena ya sí volcaba todos los archivos descomprimidos al disco duro, con 4Mb de RAM esta operación la hacía cada 2-3 disketes, tardaba algo menos de 1 minuto en volcar al disco todo lo que había descomprimido en la memoria.
Peores chapuzas y menos funcionales hice un tiempo antes, con un 286 y un Windows 3.11 que no me dejaba instalar el MS Word 6.0
El sistema operativo no era el problema, el Word 6.0 si no recuerdo mal se podía instalar sin problema en un Win 3.x o un NT 4.5x, funcionaba sin problemas con sistemas operativos de 16 bits, el problema era el procesador del ordenador, el 286.
El 286 no está programado/diseñado a nivel interno, a nivel electrónico, para trabajar con una memoria virtual como ya si lo estaba el 386 y sucesivos, por lo que si se acaba la memoria física, si uno o varios programas te comen toda la memoria RAM, el procesador no puede utilizar el disco duro como si fuera memoria RAM y el ordenador o bien acaba por bloquearse o bien va tan lento que acabas apagándolo a la brava porque es imposible hacer nada.
La instalación del Word 6.0 ya me dio pistas de que no iba a ir nada bien el tema, se tiró casi 1 horita de nada para escupir el mensaje de error diciendo que no tenía memoria virtual suficiente para continuar con la instalación...
En resumidas cuentas, lo que hice fue descomprimir en un directorio del disco duro todos los archivos de los 10 disketes del Word.
Me tiré hora y algo descomprimiendo pero "mereció la pena", sí entre comillas , el Word se ejecutó sin problema, tardó así como 5 minutos en abrirse pero lo hizo, ahora bien, era del todo inutilizable ya que la memoria del ordenador estaba hasta arriba y cada dos por tres el word accedía al disco duro para leer otra vez el programa, el word y sus librerías, se tiraba varios minutos leyendo incluso cada vez que parpadeaba el cursor, y como este no para de parpadear tampoco paraba de leer el disco...
Para escribir una sola letra te podías tirar varios siglos.
Una vez la sincronización de los precios falló y me tocó entrar a arreglarlo, al ser un *nix me era familiar pero al no ser posix me costó un rato dar con la tecla, todo era parecido pero diferente
En el caso del P6 (Pentium Pro, Pentium II, ...), hay una primera parte del procesador (frontend) que funciona en orden, al final de esta parte se asignan los registros de la instrucción a registros reales del procesador (que son muchos más), guardándose esta asociación en la RAT (Register Alias Table) (los registros que se usen como fuente se buscan en los que ya están en la RAT, los usados como destino se asocian a uno libre) y se guarda información sobre la instrucción en algo llamado Reorder Buffer (ROB). El ROB va enviando instrucciones que estén listas para ejecutarse (los registros de los que dependen ya tienen su valor válido) a unidades de ejecución que estén disponibles. Según las unidades de ejecución terminan de ejecutar las instrucciones, estas últimas se van retirando del ROB en orden.
El Pentium no es internamente RISC. Su capacidad de ejecutar en paralelo se limita a determinados pares de instrucciones, en el caso de que las dos instrucciones no estén en conflicto.
Los XT terminaron con los 286 creo.
lento comparado con qué?, porque desde luego que las operaciones en punto flotante irán muchísimo más rápidas que si no lo usas. Otra cosa es que el código se compilara para que no se use porque entonces el software sólo correría en los pocos equipos que lo tuvieran.
en.wikipedia.org/wiki/X87#Performance
Utilizar fpu en juegos 3d es viable a partir del Intel Pentium.
Me vas a decir que para cálculos en coma flotante en un 386 es más rápido usar la CPU que la NPU.
Una de dos, o lo que dices no tiene pies ni cabeza o te explicas como el culo.
- Imprecisión: Como el famoso efecto colateral de escenarios/objetos temblorosos.
- Rangos limitados: El tamaño máximo del mundo 3D es mucho mas pequeño que con los tipos de 64/80bit de la FPU