Autor: ciberkaos

  • 3. ¿Qué es una Red Virtual?

    3. ¿Qué es una Red Virtual?

    Muchas aplicaciones y servicios precisan de una infraestructura de red formada por varios equipos conectados entre sí. Esto puede suceder tanto cuando trabajamos en producción como para pruebas de calidad o en el ámbito académico. A veces no nos resulta interesante o no compensa económicamente hacerlo con hardware y cableado real. Es por eso por lo que disponemos de la posibilidad de crear redes complejas de forma virtual, donde administraremos diferentes equipos virtuales desde un solo equipo anfitrión.

    En este apartado vamos a aprender a crear redes virtuales, ya sea para instalar servidores aislados, entornos de prueba y escenarios profesionales de forma más flexible, económica y segura.

    ¿Qué es una Red Virtual?

    En una red virtual no solo tenemos virtualizados los equipos con sistemas operativos, sino que además virtualizamos todos los elementos de la infraestructura como tarjetas de red, cables, switches y routers.

    En otras palabras, una red virtual reproduce una red real, pero lo hace dentro de un entorno virtualizado.

    Por ejemplo, vamos a imaginar que tenemos que montar un pequeño laboratorio para simular la red de una empresa, en esta red queremos configurar un servidor, comprobar que los clientes pueden acceder a las aplicaciones y servicios, detectar errores y vulnerabilidades.

    Al hacerlo mediante una red virtual podremos trabajar con un caso de uso muy próximo a la realidad, pero en un entorno más accesible y seguro para el aprendizaje.

    VLANs y Redes Virtuales

    Aunque no son exactamente lo mismo, las VLAN están muy relacionadas con la virtualización de redes. Una VLAN permite organizar la red física en varias redes independientes. En entornos virtuales podemos integrar máquinas virtuales en redes segmentadas reales o crear nuevas redes.

    Vamos a hacer una comparativa entre crear una VLAN física frente a una en Red virtual

    Ventajas

    VentajaDescripción
    FlexibilidadPermiten levantar sistemas y redes en poco tiempo.
    Ahorro de costesReducen la necesidad de hardware físico.
    EscalabilidadEs fácil ampliar el número de máquinas o segmentos de red.
    AislamientoSe pueden crear entornos seguros y separados del resto.
    ReutilizaciónUn mismo host puede albergar múltiples laboratorios o servicios. Duplicarlos, clonarlos…
    Rapidez de despliegueLos cambios se aplican mucho más rápido que en infraestructuras físicas y no tenemos que desplazarnos.

    Desventajas

    DesventajasDescripción
    Dependencia del hostSi el equipo anfitrión falla, pueden caer varias máquinas y redes a la vez.
    Posibles cuellos de botellaTodos los sistemas virtuales comparten recursos de la máquina anfitrión.
    Riesgo de mala segmentaciónUna mala configuración puede mezclar redes o exponer servicios sin querer.
    Falsa sensación de aislamientoSi no se diseña bien, una red supuestamente privada, puede terminar conectada al exterior.

    Tipos de Conexiones en Redes Virtuales

    Cuando utilizamos hipervisores como, VirtualBox, VMware, Hyper-V, Proxmox, KVM/QEMU, etc. al crear las máquinas virtuales disponemos de una o varias interfaces de red virtuales, que se comportan como tarjetas de red físicas y también Switch y routers para que interactúen entre sí.

    De tal modo que podemos simular cualquier topología de red que deseemos implementar. Existen varios tipos de red al utilizar hipervisores, las cuatro más comunes son:

    • NAT: Esta opción permite que una máquina virtual pueda acceder a internet utilizando el equipo anfitrión como router. Como ya hemos utilizado anteriormente, sirve para aislar un solo sistema de nuestra red manteniendo un acceso a internet.
    • Red NAT: Mantiene las restricciones del caso anterior NAT, pero nos permite simular más de un dispositivo pudiendo crear infraestructuras de Red complejas con acceso a internet, pero que no tengan comunicación con la red principal. Muy útiles para realizar pruebas de implantaciones que precisen de varios equipos para realizar pruebas de seguridad o calidad.
    • Adaptador puente o Bridged: Las máquinas virtuales se integran en la red física como equipos reales, son totalmente visibles al resto de la red. Conectarlas en este modo resulta útil cuando queremos ampliar algún servicio en nuestra red sin tener que implementar nuevo hardware a nuestra red.
    • Red Interna: La opción de Red Interna actúa de forma muy similar a las redes NAT donde podemos crear nuevas redes, pero en este caso sin acceso a internet. Este tipo es muy útil para laboratorios de ciberseguridad, dado que tiene un aislamiento absoluto.
    • Host-only: Esta opción es la menos versátil, pues solo permite comunicación creando un canal privado con el host o equipo anfitrión.
    Caso de Uso Para entender todo esto mucho mejor, vamos a realizar un caso de uso paso a paso. Desde el departamento de desarrollo nos han pedido que creemos una subred con tres equipos aislados del resto de la red de la empresa, pero con conexión a internet. La red contendrá dos dispositivos clientes y un servidor web Ubuntu Server con Apache2 y conexión vía SSH, para que los desarrolladores puedan realizar pruebas de funcionamiento y en encontrar posibles errores del proyecto que están realizado antes de subirlo a producción. Nos solicitan que los equipos clientes tengan diferentes sistemas operativos, uno con Ubuntu Desktop y otro con Windows.

    Para resolver la petición del departamento de desarrolladores, vamos a crear una red virtual que permita la comunicación entre tres máquinas, manteniéndolas aisladas de la red principal de la empresa, pero con acceso a Internet. Para ello utilizaremos un hipervisor como VirtualBox, aunque se podría realizar en otras plataformas de virtualización como VMWare.

    Diseño de la topología

    El primer paso será definir el tipo de red que queremos implantar. En este caso, la opción más adecuada es utilizar una Red NAT dentro de VirtualBox. Este tipo de red cumple con los requerimientos solicitados permitiendo que varias máquinas virtuales compartan una misma subred privada, puedan comunicarse entre sí y, además, tengan salida a Internet a través del equipo anfitrión.

    EquipoDirección IPMáscaraPuerta de enlace
    Ubuntu Desktop10.0.2.10255.255.255.010.0.2.1
    Windows10.0.2.11255.255.255.010.0.2.1
    Ubuntu Server10.0.2.12255.255.255.010.0.2.1

    Dentro de VirtualBox, debemos acceder al apartado de herramientas de red y crear una Red NAT nueva para las tres máquinas virtuales. Por ejemplo, podemos crear una red con estas características:

    • Nombre de la red: RedDesarrollo
    • Rango de red: 10.0.2.0/24
    Panel de configuración de Red NAT en VirtualBox

    Es importante que todas estén conectadas a la misma red virtual; de lo contrario, no podrán comunicarse entre sí.

    Partiendo de tres máquinas ya creadas y procederemos a configurar la red de cada una de ellas.

    Seleccionamos la máquina Ubuntu Desktop y en la configuración de VirtualBox. En el campo conectado a, elegimos la opción Red NAT y en el nombre de la red seleccionamos RedDesarrollo. Guardamos los cambios y pasamos a la siguiente máquina.

    Panel de configuración de adaptador de red en VirtualBox

    Repetimos el mismo procedimiento con la máquina Windows y la de Ubuntu Server poniendo en todas el tipo de Red NAT y nombre de la red RedDesarrollo.

    Ahora ya tenemos los equipos en una única red, el siguiente paso es realizar la configuración de las direcciones IPs según la tabla de la topología y realizar las pruebas para ver que todo funciona.

    Si la red NAT está funcionando correctamente, cada máquina debería obtener una dirección IP perteneciente a la misma subred.

    Por ejemplo, en los sistemas Linux podemos utilizar en la terminal el comando:

    ip a

    Y comprobamos que los equipos pertenecen a la red de redDesarrollo al tener una IP con la dirección 10.0.2.X.

    Captura de terminal Linux mostrando la IP asignada al dispositivo.

    El último paso que debemos realizar antes de entregar el despliegue sería ver si las máquinas tienen conexión entre sí y acceso a internet. Para ello desde la terminal de las diferentes máquinas realizaremos un “ping” a los dispositivos y a una IP de un servicio de internet.

    Captura de terminal Linux con resultados de la conexión

    Conclusión

    Gracias a las redes virtuales es posible segmentar servicios, aislar entornos, conectar servidores, automatizar despliegues y administrar infraestructuras complejas de forma rápida y segura. Por ello, comprender cómo se implantan y configuran no solo resulta útil para el aprendizaje, sino que constituye también una competencia esencial para trabajar en administración de sistemas, virtualización, cloud y redes empresariales modernas, para organizar entornos mucho más grandes en plataformas como Proxmox, centros de datos virtualizados o servicios en la nube como AWS.

  • PC-RETO 1: Evolución del PC doméstico

    PC-RETO 1: Evolución del PC doméstico

    La siguiente tabla muestra una propuesta de ordenadores bien montados y representativos de cada época, desde 1980 hasta 2015, pensados para recrearlos en entornos como PCem, 86Box, VirtualBox o simplemente para entender cómo era un PC equilibrado y potente en cada momento histórico.

    🎧 Audio del tema
    Escucha este breve audio para repasar las ideas principales este proyecto.

    Nota: no se trata siempre del equipo más caro del mercado, sino de una configuración realista, potente y coherente para su año.


    AñoMicroprocesadorRAMAlmacenamientoGráficaSonidoUnidad óptica / disqueteSistema operativo recomendadoUso típico
    1980Intel 8088 a 4.77 MHz64 KB – 256 KBSin disco duro, 1 o 2 disqueteras de 5,25″MDA o CGAAltavoz internoDisquetera 5,25″PC DOS 1.0Ofimática básica, programación, primeros juegos de PC
    1985Intel 80286 a 6–12 MHz512 KB – 1 MBDisco duro de 20–40 MBEGAAltavoz interno o tarjeta muy básicaDisquetera 5,25″ 1.2 MBMS-DOS 3.1 / 3.2Software profesional, bases de datos, juegos más avanzados
    1990Intel 80386DX a 33 MHz4 MBDisco duro de 80–120 MBVGASound Blaster 1.5 / ProDisquetera 3,5″ 1.44 MBMS-DOS 5.0 + Windows 3.0 opcionalJuegos DOS, productividad, primeros entornos gráficos serios
    1995Intel Pentium 100 / 133 MHz16 MBDisco duro de 850 MB – 1.6 GBSVGA PCI (1–2 MB VRAM)Sound Blaster 16 / AWE32Disquetera 3,5″ + CD-ROM 4x / 8xMS-DOS 6.22 + Windows 95Multimedia, CD-ROM, juegos DOS avanzados y primeros juegos Windows 95
    2000Pentium III 733 MHz o AMD Athlon 700–900 MHz128 MBDisco duro de 20–30 GBNVIDIA GeForce 2 GTS o 3dfx Voodoo3 3000Sound Blaster Live!CD-ROM / DVD-ROM / CD-RWWindows 98 SE o Windows 2000Juegos 3D, internet, música MP3, software multimedia
    2005Pentium 4 3.0 GHz o Athlon 64 3200+1 GBDisco duro de 120–200 GBGeForce 6600 GT / 6800 GT o Radeon 9800 Pro / X800AC’97 o Sound Blaster AudigyDVD-RWWindows XP SP2Juegos DirectX 8/9, internet, multimedia, grabación DVD
    2010Intel Core i5 750 o i7 8604 GBDisco duro de 500 GBGeForce GTX 460 o Radeon HD 5850HD Audio integradoDVD-RWWindows 7Juegos modernos de la época, Steam, multimedia HD
    2015Intel Core i5 4690K o i7 4790K8–16 GBSSD de 250 GB + HDD de 1 TBGTX 970 o Radeon R9 390HD Audio integradoDVD-RW opcionalWindows 10Gaming moderno, productividad, edición, streaming

    Comentarios por época

    AñoComentario histórico
    1980Ordenadores muy básicos, centrados en texto, programación y software profesional simple. Los juegos aún eran muy limitados.
    1985El PC empieza a consolidarse como herramienta seria de trabajo. El disco duro ya marca una gran diferencia.
    1990La época dorada del DOS empieza a despegar con fuerza. Aparecen mejores juegos, mejor sonido y los primeros entornos gráficos realmente utilizables.
    1995Uno de los momentos más interesantes del PC: convivencia entre DOS y Windows 95, explosión del CD-ROM y auge del PC multimedia.
    2000El 3D ya está plenamente asentado. Es una gran época para juegos clásicos de finales de los 90 y principios de los 2000.
    2005Windows XP domina claramente. Se consolida internet, los DVDs, el audio integrado y los juegos DirectX 9.
    2010El PC ya entra en una etapa muy moderna, con Windows 7 como sistema de referencia y el auge del juego digital.
    2015SSD, tarjetas gráficas potentes y Windows 10 marcan una plataforma ya completamente actual en muchos aspectos.

    Configuraciones más recomendables para montar máquinas virtuales retro

    EntornoAño recomendadoConfiguración sugerida
    PCem / 86Box1990386DX-33, 4 MB RAM, VGA, Sound Blaster Pro, MS-DOS 5.0
    PCem / 86Box1995Pentium 100, 16 MB RAM, SVGA PCI, Sound Blaster 16, CD-ROM, Windows 95
    PCem / 86Box2000Pentium II / III, 64–128 MB RAM, Voodoo3 o GeForce 2, Sound Blaster Live!, Windows 98 SE
    VirtualBox20051 GB RAM, 20–40 GB de disco virtual, Windows XP SP2 / SP3
    VirtualBox20102–4 GB RAM, disco virtual moderno, Windows 7

    Selección ideal para un proyecto retro equilibrado

    Si quieres montar varias máquinas para cubrir bien la evolución del PC, una selección muy buena sería esta:

    MáquinaRepresentaSistema
    1985PC clásico de trabajo y primeros juegos avanzadosMS-DOS 3.x
    1990Época fuerte de DOS y primeros WindowsMS-DOS 5.0 + Windows 3.0
    1995Transición DOS / Windows 95 y explosión multimediaWindows 95
    2000Auge del 3D y de los grandes clásicos de PCWindows 98 SE
    2005Dominio absoluto de Windows XPWindows XP SP2/SP3

    Conclusión

    Montar varias máquinas virtuales siguiendo esta evolución permite recrear de forma bastante fiel la historia del PC doméstico y del PC de juegos. Cada época tiene una personalidad muy marcada:

    • 1980–1985: primeros PCs y software muy básico
    • 1990–1995: gran crecimiento del DOS, sonido y multimedia
    • 2000–2005: consolidación total del 3D y de Windows
    • 2010–2015: entrada en la informática moderna
  • PC-RETO 2: Instalación y configuración PCEM

    PC-RETO 2: Instalación y configuración PCEM

    PCem es un emulador de ordenadores PC antiguos. Su objetivo es reproducir el comportamiento de hardware real de distintas épocas. Esto permite instalar sistemas operativos antiguos y ejecutar software que, en máquinas modernas, podría no funcionar correctamente.

    PCem puede emular diferentes familias de equipos, desde sistemas 8086/286 hasta máquinas Pentium, Pentium II o configuraciones más avanzadas según la versión y ROM disponibles. La lista de máquinas compatibles depende de los ficheros ROM colocados en la carpeta adecuada. La documentación pública de PCem muestra que cada modelo necesita uno o varios archivos ROM concretos dentro de subcarpetas específicas de roms.


    7. Diferencia entre PCem y VirtualBox

    CaracterísticaPCemVirtualBox / VMware / Proxmox
    Enfoque principalEmulación de PCs antiguosVirtualización de sistemas modernos
    HardwareEmula placas, BIOS, tarjetas y CPUs antiguasUsa hardware virtual moderno
    RendimientoMás lento, pero más fiel al hardware antiguoMás rápido
    Uso típicoMS-DOS, Windows 3.11, Windows 95, Windows 98, juegos antiguosLinux, Windows moderno, servidores
    BIOSDepende de ROMs específicasBIOS/UEFI integrada en el hipervisor
    Aprendizaje históricoMuy altoMedio
    Compatibilidad con juegos antiguosMuy buena si se configura bienVariable

    Parte 1: instalación de PCem

    1. Instalación en Windows

    Paso 1. Descargar PCem

    El alumno debe descargar PCem desde una fuente fiable. Según la versión usada, puede venir como programa ya compilado o como código fuente.

    https://pcem-emulator.co.uk/downloads.html

    En Windows normalmente se descarga una versión comprimida.

    Paso 2. Crear una carpeta de trabajo

    Crear una carpeta, por ejemplo:

    C:\Emuladores\PCem

    Dentro de esa carpeta se recomienda organizar el material así:

    PCem/
    ├── pcem.exe
    ├── roms/
    ├── discos/
    ├── isos/
    ├── floppies/
    ├── drivers/
    └── capturas/

    Paso 3. Ejecutar PCem por primera vez

    Ejecutar:

    pcem.exe

    Si PCem no encuentra ninguna BIOS válida, puede abrirse sin máquinas disponibles o mostrar errores relacionados con ROMs ausentes.

    Esto es normal: antes de crear la máquina hay que colocar las BIOS en la carpeta correcta.



    Parte 2: preparación de BIOS y ROMs

    1. ¿Qué es la BIOS?

    La BIOS es el firmware básico de un PC clásico. Se ejecuta al encender el equipo y realiza tareas como:

    • Inicializar la placa base.
    • Comprobar la memoria RAM.
    • Detectar unidades de disco.
    • Inicializar teclado y pantalla.
    • Permitir entrar en la configuración del sistema.
    • Buscar un dispositivo de arranque.
    • Cargar el sistema operativo.

    En ordenadores antiguos, la BIOS era mucho más visible para el usuario. Configurar mal el disco duro, el orden de arranque o la disquetera podía impedir que el sistema arrancase.

    https://archive.org/details/pcem-v-17-roms


    2. ¿Por qué PCem necesita BIOS?

    PCem no se limita a simular “un PC genérico”. Emula modelos concretos de placa o chipsets. Muchas de esas máquinas necesitan su BIOS original o una BIOS compatible.

    Por ejemplo, la documentación pública del proyecto muestra modelos que requieren rutas y nombres concretos de ROM, como máquinas IBM AT, Compaq, placas Socket 7 o placas Slot 1.


    3. Estructura de carpetas de ROM

    Una posible estructura sería:

    roms/
    ├── ibmat/
    │ ├── at111585.0
    │ └── at111585.1
    ├── ami486/
    │ └── bios.bin
    ├── ga686bx/
    │ └── 6BX.F2a
    └── video/
    └── vga.rom

    La estructura exacta depende de la máquina seleccionada. PCem suele esperar nombres concretos. Si el nombre del archivo no coincide, la máquina puede no aparecer o puede fallar al arrancar.


    4. Comprobación de BIOS detectadas

    Una vez copiadas las ROMs:

    1. Abrir PCem.
    2. Crear una nueva máquina.
    3. Abrir la lista de modelos disponibles.
    4. Comprobar si aparecen nuevas placas o equipos.

    Si no aparece la máquina deseada, revisar:

    • Nombre exacto del archivo.
    • Carpeta correcta.
    • Mayúsculas y minúsculas.
    • Si falta alguna ROM adicional.
    • Si la ROM está comprimida dentro de un .zip.
    • Si PCem está buscando las ROMs en otra carpeta.

    Parte 3: creación de una máquina virtual de ejemplo

    Máquina propuesta

    Vamos a crear una máquina tipo PC 486 con MS-DOS / FreeDOS.

    Esta opción es ideal para una primera práctica porque:

    • Es más sencilla que Windows 95/98.
    • Permite entender bien la BIOS.
    • Obliga a trabajar con disquetes, particiones y formateo.
    • Consume pocos recursos.
    • Es perfecta para explicar hardware clásico.

    1. Configuración objetivo

    ElementoConfiguración propuesta
    Tipo de máquina486 compatible
    CPUIntel 486DX2 a 66 MHz
    RAM16 MB
    Tarjeta gráficaVGA o SVGA compatible
    SonidoSound Blaster 16
    Disco duroIDE de 512 MB
    Disquetera3.5” 1.44 MB
    CD-ROMOpcional
    Sistema operativoFreeDOS o MS-DOS
    RatónSerial o PS/2, según disponibilidad
    RedNo necesaria en esta primera práctica

    Parte 4: crear la configuración en PCem

    Paso 1. Abrir PCem

    Abrir el programa PCem.

    Seleccionar:

    New machine

    o la opción equivalente para crear una nueva configuración.


    Paso 2. Asignar nombre a la máquina

    Nombre recomendado:

    PC_486_DOS_Practica

    El alumno debe usar un nombre claro. Por ejemplo:

    NombreAlumno_PC486_DOS

    Paso 3. Seleccionar la placa base

    Seleccionar una placa compatible con 486.

    Ejemplos posibles, dependiendo de las ROM disponibles:

    AMI 486
    Award 486
    Socket 3 compatible

    Nota para el profesor:
    El nombre exacto dependerá de las ROM instaladas. Si se quiere evitar confusión, conviene preparar previamente un paquete de trabajo con una máquina concreta ya verificada en el aula.


    Paso 4. Seleccionar CPU

    Elegir:

    Intel 486DX2/66

    Si no aparece exactamente esa CPU, elegir una parecida:

    486DX/33
    486DX2/50
    486DX2/66

    Paso 5. Configurar memoria RAM

    Asignar:

    16 MB

    Para MS-DOS es más que suficiente.

    No conviene asignar cantidades absurdamente altas, porque una parte del objetivo es comprender las limitaciones reales de la época.


    Paso 6. Configurar vídeo

    Seleccionar una tarjeta gráfica compatible.

    Opciones recomendadas:

    VGA
    SVGA
    S3 Trio
    Cirrus Logic

    Para una primera práctica con DOS, una VGA sencilla es suficiente.


    Paso 7. Configurar sonido

    Seleccionar:

    Sound Blaster 16

    Configuración típica:

    ParámetroValor habitual
    Dirección I/O220
    IRQ5 o 7
    DMA1
    High DMA5

    Esta parte será útil más adelante si se instalan juegos o programas multimedia.


    Paso 8. Configurar disquetera

    Añadir una disquetera:

    3.5" 1.44 MB

    Será necesaria para arrancar con un disquete de instalación o de arranque.


    Paso 9. Crear disco duro virtual

    Crear un disco duro nuevo.

    Tamaño recomendado:

    512 MB

    Nombre del archivo:

    discos/pc486_dos_512mb.img

    Tipo:

    IDE

    En PCs antiguos, el disco duro se identificaba mediante geometría CHS:

    • Cylinders
    • Heads
    • Sectors

    Muchas BIOS antiguas permiten autodetección, pero otras exigen introducir manualmente los datos.


    Parte 5: primera arrancada y entrada en BIOS

    Paso 1. Iniciar la máquina

    Arrancar la máquina creada.

    Es posible que aparezca un mensaje similar a:

    No boot device
    Disk boot failure
    Insert system disk
    CMOS checksum error
    Press F1 to continue
    Press DEL to enter Setup

    Esto es normal. Todavía no hemos configurado la BIOS ni instalado ningún sistema operativo.


    Paso 2. Entrar en la BIOS

    Durante el arranque, pulsar la tecla correspondiente.

    Las teclas más habituales son:

    TeclaUso habitual
    DEL / SuprEntrar en BIOS Award/AMI
    F1Continuar o entrar en configuración
    F2Setup en algunas BIOS
    ESCMenú o salida
    F10Guardar y salir

    En muchas BIOS antiguas, la tecla más habitual es:

    Supr / DEL

    Paso 3. Configurar fecha y hora

    Dentro de la BIOS:

    1. Ir a la pantalla principal.
    2. Configurar fecha.
    3. Configurar hora.

    Ejemplo:

    Date: 05/04/1995
    Time: 12:00:00

    Se puede usar una fecha histórica para contextualizar la práctica.


    Paso 4. Configurar disquetera

    Buscar el apartado:

    Standard CMOS Setup

    Configurar:

    Drive A: 1.44M, 3.5 in.
    Drive B: None

    Paso 5. Configurar disco duro

    En la opción de discos IDE:

    Primary Master: Auto
    Primary Slave: None
    Secondary Master: None
    Secondary Slave: None

    Si la BIOS permite autodetección:

    IDE HDD Auto Detection

    Seleccionar el disco detectado y aceptar.

    Si pide geometría manual, usar la que indique PCem al crear el disco.


    Paso 6. Configurar orden de arranque

    Buscar:

    BIOS Features Setup
    Boot Sequence

    Configurar:

    A, C

    o:

    Floppy, HDD

    Esto significa que primero intentará arrancar desde disquete y después desde disco duro.


    Paso 7. Guardar cambios

    Seleccionar:

    Save & Exit Setup

    Normalmente se confirma con:

    Y

    Después, la máquina se reiniciará.


    Parte 6: instalación de FreeDOS o MS-DOS

    Para evitar problemas legales, en clase puede usarse FreeDOS, que es libre y compatible con muchos programas de DOS.

    Descargar Sistemas operativos (winworldpc.com/library/operating-systems)

    Paso 1. Montar imagen de disquete o ISO

    En PCem, montar la imagen de instalación:

    freedos.img

    o, si se usa CD-ROM:

    freedos.iso

    Para una primera práctica, recomiendo usar disquete o CD según la configuración preparada por el profesor.


    Paso 2. Arrancar desde el medio de instalación

    Iniciar la máquina.

    Si todo está correcto, aparecerá el instalador o el prompt de DOS:

    A:\>

    Paso 3. Crear partición con FDISK

    Ejecutar:

    fdisk

    Seleccionar:

    Create DOS partition
    Create Primary DOS Partition
    Use maximum available size
    Set partition active

    Después, reiniciar la máquina.


    Paso 4. Formatear el disco duro

    Tras reiniciar, volver a arrancar desde el disquete o medio de instalación.

    Ejecutar:

    format c: /s

    El parámetro /s copia los archivos básicos del sistema para que el disco sea arrancable.

    Si se usa FreeDOS, el proceso puede variar ligeramente, pero la idea es la misma: crear partición, formatear e instalar el sistema.


    Paso 5. Comprobar arranque desde disco duro

    Apagar la máquina.

    Quitar el disquete o ISO de arranque.

    Iniciar de nuevo.

    Si todo ha salido bien, debería aparecer:

    C:\>

    La máquina ya arranca desde su disco duro virtual.


    Parte 7: configuración básica del sistema DOS

    1. Crear estructura de carpetas

    Ejecutar:

    c:
    md DOS
    md DRIVERS
    md JUEGOS
    md UTIL
    md DOCUMENT

    Comprobar con:

    dir

    2. Crear o editar AUTOEXEC.BAT

    El archivo AUTOEXEC.BAT se ejecuta automáticamente al arrancar DOS.

    Ejemplo básico:

    @ECHO OFF
    PROMPT $p$g
    PATH C:\DOS;C:\DRIVERS;C:\UTIL
    CLS
    ECHO Bienvenido al PC 486 emulado con PCem

    3. Crear o editar CONFIG.SYS

    El archivo CONFIG.SYS carga controladores básicos.

    Ejemplo:

    DEVICE=C:\DOS\HIMEM.SYS
    DOS=HIGH,UMB
    FILES=40
    BUFFERS=30
    LASTDRIVE=Z

    4. Reiniciar y comprobar

    Reiniciar la máquina.

    Comprobar que aparece el mensaje:

    Bienvenido al PC 486 emulado con PCem

    Parte 8: instalación de drivers

    1. Driver de ratón

    Copiar un driver de ratón compatible, por ejemplo:

    MOUSE.COM

    Guardar en:

    C:\DRIVERS\MOUSE

    Modificar AUTOEXEC.BAT:

    C:\DRIVERS\MOUSE\MOUSE.COM

    2. Driver de CD-ROM

    Para usar CD-ROM en DOS se necesitan normalmente dos elementos:

    • Un controlador en CONFIG.SYS.
    • El programa MSCDEX.EXE en AUTOEXEC.BAT.

    Ejemplo de CONFIG.SYS:

    DEVICE=C:\DRIVERS\CDROM\OAKCDROM.SYS /D:MSCD001

    Ejemplo de AUTOEXEC.BAT:

    C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D

    Después de reiniciar, el CD-ROM debería aparecer como:

    D:

    3. Configuración de Sound Blaster

    Añadir al AUTOEXEC.BAT:

    SET BLASTER=A220 I5 D1 H5 T6
    SET SOUND=C:\SB16

    Explicación:

    ParámetroSignificado
    A220Dirección base 220h
    I5IRQ 5
    D1DMA 1
    H5DMA alta 5
    T6Tipo Sound Blaster 16

    Parte 9: ejemplo de máquina virtual alternativa con Windows 95

    Una vez terminada la práctica con DOS, se puede hacer una segunda máquina más avanzada.

    Configuración recomendada

    ElementoConfiguración
    MáquinaSocket 7 / Pentium
    CPUPentium 133 MHz
    RAM32 MB o 64 MB
    Disco duro2 GB
    GráficaS3 Trio64 / S3 ViRGE
    SonidoSound Blaster 16
    CD-ROMIDE
    Sistema operativoWindows 95 OSR2
    Disquetera3.5” 1.44 MB

    PCem incluye o ha incluido soporte para muchas máquinas de los años 90, incluyendo placas Socket 7 y Slot 1, dependiendo de la versión y de las ROM instaladas. Por ejemplo, la documentación pública lista configuraciones como FIC VA-503+ o Gigabyte GA-686BX con CPUs Pentium, AMD K6 o Pentium II, siempre que estén disponibles las ROM correspondientes.


    Pasos resumidos para Windows 95

    1. Crear máquina Pentium.
    2. Asignar 32 o 64 MB de RAM.
    3. Crear disco duro de 2 GB.
    4. Activar CD-ROM.
    5. Montar disquete de arranque de Windows 95/98 con soporte CD-ROM.
    6. Arrancar desde disquete.
    7. Ejecutar fdisk.
    8. Crear partición primaria.
    9. Reiniciar.
    10. Formatear:
    format c: /s
    1. Entrar en la unidad de CD-ROM:
    D:
    1. Ejecutar:
    setup
    1. Seguir el instalador de Windows 95.
    2. Instalar drivers de vídeo y sonido si es necesario.
    3. Documentar problemas encontrados.

    Problemas frecuentes y soluciones

    Problema 1: la máquina no aparece en PCem

    Causa probable: faltan ROMs o están mal colocadas.

    Solución:

    • Revisar carpeta roms.
    • Revisar nombres exactos.
    • Revisar mayúsculas/minúsculas.
    • Comprobar si la ROM debe ir dentro de una subcarpeta concreta.

    Problema 2: aparece “CMOS checksum error”

    Causa: la BIOS no tiene configuración guardada todavía.

    Solución:

    1. Entrar en BIOS.
    2. Configurar fecha, hora, disco y disquetera.
    3. Guardar cambios.
    4. Reiniciar.

    Problema 3: no arranca desde disquete

    Causa: orden de arranque incorrecto o imagen mal montada.

    Solución:

    • Configurar Boot Sequence como A, C.
    • Comprobar que la imagen de disquete está montada.
    • Comprobar que la imagen es arrancable.

    Problema 4: no detecta el disco duro

    Causa: disco no creado, no conectado o no detectado en BIOS.

    Solución:

    • Revisar configuración IDE.
    • Entrar en BIOS.
    • Usar IDE HDD Auto Detection.
    • Guardar cambios.

    Problema 5: después de FDISK sigue sin arrancar

    Causa: falta formatear con archivos de sistema o partición no activa.

    Solución:

    Ejecutar:

    fdisk

    Comprobar que la partición primaria está activa.

    Después:

    format c: /s

    Problema 6: el CD-ROM no aparece en DOS

    Causa: faltan drivers de CD-ROM.

    Solución:

    Revisar CONFIG.SYS:

    DEVICE=C:\DRIVERS\CDROM\OAKCDROM.SYS /D:MSCD001

    Revisar AUTOEXEC.BAT:

    C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D

    Problema 7: el sonido no funciona

    Causa: configuración incorrecta de Sound Blaster.

    Solución:

    Comprobar que los valores de PCem coinciden con la variable BLASTER:

    SET BLASTER=A220 I5 D1 H5 T6
  • PC-RETO 3: Instalación, carga de BIOS y creación de una máquina virtual retro con 86Box

    PC-RETO 3: Instalación, carga de BIOS y creación de una máquina virtual retro con 86Box

    n esta práctica vamos a trabajar con 86Box, un emulador de ordenadores compatibles x86 pensado para recrear equipos antiguos con bastante fidelidad. A diferencia de VirtualBox, VMware o Proxmox, que están orientados principalmente a virtualizar sistemas modernos, 86Box intenta reproducir el comportamiento de hardware real de distintas épocas: placas base, BIOS, procesadores 286, 386, 486, Pentium, tarjetas gráficas, tarjetas de sonido, controladoras IDE, disqueteras, CD-ROM y otros componentes clásicos.

    Este proyecto tiene como objetivo que el alumno no solo “instale un sistema operativo antiguo”, sino que entienda cómo arrancaba y se configuraba un PC clásico: qué papel tenía la BIOS, cómo se detectaban los discos, cómo se configuraba el orden de arranque y por qué era necesario cargar controladores manualmente.

    86Box necesita un conjunto de ROMs para emular correctamente muchos equipos. Estas ROMs incluyen BIOS de sistema y ROMs opcionales de tarjetas de expansión, organizadas en carpetas según el tipo de dispositivo o modelo emulado. La propia documentación de 86Box indica que, sin un conjunto de ROMs válido, el programa no podrá iniciar correctamente determinadas máquinas.



    ¿Qué es 86Box?

    86Box es un emulador de ordenadores compatibles x86. Su finalidad es reproducir el comportamiento de PCs antiguos de forma más fiel que una máquina virtual moderna.

    Con 86Box podemos emular equipos de distintas generaciones:

    • 8086 / 8088.
        1. Pentium.
        2. Pentium MMX.
        3. Pentium II.
        4. Otros sistemas compatibles, según la versión y las ROMs disponibles.

        La versión estable más reciente publicada en la página oficial de 86Box es la v5.3, lanzada el 21 de diciembre de 2025. Esta versión incluye mejoras de rendimiento, correcciones y nuevo hardware soportado.


        Diferencia entre 86Box y PCem

        86Box nació como una continuación o evolución del trabajo realizado alrededor de PCem, pero actualmente se mantiene como un proyecto propio y con desarrollo activo.

        CaracterísticaPCem86Box
        Tipo de programaEmulador de PCs antiguosEmulador de PCs antiguos
        Estado actualProyecto histórico muy usadoProyecto activo y actualizado
        Uso principalEmular hardware retroEmular hardware retro con más hardware soportado
        BIOS/ROMsNecesita ROMs específicasNecesita ROMs específicas
        ConfiguraciónManual, algo más clásicaIncluye gestor de máquinas virtuales en versiones recientes
        Ideal paraDOS, Windows 3.x, Windows 95/98DOS, Windows 3.x, Windows 95/98 y más configuraciones
        DificultadMediaMedia

        86Box incluye actualmente un gestor de máquinas virtuales que permite crear, administrar, arrancar y controlar varias configuraciones desde una misma interfaz. La documentación oficial indica que, al abrir 86Box, se inicia este gestor de máquinas virtuales, aunque sigue considerándose una función en evolución.


        Material necesario

        Para realizar la práctica necesitaremos:

        • 86Box instalado.
        • Conjunto de ROMs/BIOS compatible con 86Box.
        • Imagen de instalación de un sistema operativo retro.
        • Imagen de disquete de arranque, si es necesaria.
        • Drivers de CD-ROM, ratón, sonido o vídeo, según el sistema elegido.
        • Espacio en disco para crear discos duros virtuales.
        • Capturador de pantalla para documentar el proceso.

        Descargas:


        86Box:
        https://86box.net/#downloads

        Bios 86Box (Roms set)

        https://github.com/86box/roms/releases

        Sistemas operativos
        https://winworldpc.com/library/operating-systems


        Aviso importante sobre BIOS y ROMs

        Las BIOS y ROMs son ficheros que pertenecen al firmware de equipos y tarjetas reales. En muchos casos pueden estar protegidas por derechos de autor.

        Para una práctica educativa, lo correcto es:

        • Usar ROMs obtenidas de forma legítima.
        • No redistribuir BIOS propietarias sin permiso.
        • Documentar qué ROMs se han usado.
        • No mezclar ROMs aleatorias sin saber para qué máquina sirven.

        86Box dispone de documentación específica sobre el conjunto de ROMs y explica que estas ROMs incluyen BIOS de sistema y ROMs de tarjetas de expansión. También indica que el conjunto de ROMs se organiza por directorios según el tipo de dispositivo o modelo.


        Instalación de 86Box

        1. Descarga del programa

        El primer paso es descargar 86Box desde su página oficial o desde su repositorio de GitHub.

        Conviene usar una versión estable, especialmente en clase. Las versiones experimentales pueden incluir funciones nuevas, pero también más errores.


        2. Organización de carpetas

        Antes de empezar, crearemos una carpeta de trabajo.

        Ejemplo en Windows:

        C:\Emuladores\86Box

        Dentro de esa carpeta podemos organizar el material así:

        86Box/
        ├── 86Box.exe
        ├── roms/
        ├── maquinas/
        ├── discos/
        ├── isos/
        ├── disquetes/
        ├── drivers/
        └── capturas/

        Ejemplo en Linux o macOS:

        ~/Emuladores/86Box/
        ├── 86Box
        ├── roms/
        ├── maquinas/
        ├── discos/
        ├── isos/
        ├── disquetes/
        ├── drivers/
        └── capturas/

        La carpeta más importante al principio será:

        roms/

        Ahí es donde colocaremos el conjunto de BIOS y ROMs que usará el emulador.


        7. Carga de BIOS y ROMs en 86Box

        1. ¿Para qué sirven las ROMs?

        86Box necesita ROMs para poder emular determinados equipos y tarjetas. Estas ROMs pueden incluir:

        • BIOS de la placa base.
        • BIOS de tarjetas gráficas.
        • ROMs de controladoras.
        • ROMs de tarjetas de red.
        • ROMs de tarjetas de sonido.
        • Otros firmwares necesarios para hardware concreto.

        Sin estas ROMs, algunas máquinas no aparecerán como disponibles o no arrancarán correctamente.


        2. Carpeta de ROMs

        La documentación de 86Box explica que el conjunto de ROMs debe extraerse en una ubicación soportada por el emulador. En algunos sistemas se puede colocar la carpeta roms junto al ejecutable. También existen diferencias según versión y sistema operativo, por lo que conviene comprobar la ruta concreta en la documentación o en la propia interfaz del programa.

        Ejemplo de estructura:

        86Box/
        ├── 86Box.exe
        └── roms/
        ├── machines/
        ├── video/
        ├── sound/
        ├── network/
        └── hdd/

        No debemos dejar las ROMs comprimidas si la documentación indica que deben estar extraídas.


        Comprobación de ROMs

        Una vez colocadas las ROMs:

        1. Abrimos 86Box.
        2. Entramos en el gestor de máquinas.
        3. Creamos una nueva máquina.
        4. Revisamos la lista de placas base disponibles.
        5. Comprobamos que aparecen modelos de máquinas.

        Si no aparece ninguna máquina o aparece un error de ROMs, debemos revisar:

        • Si la carpeta se llama exactamente roms.
        • Si está en la ruta correcta.
        • Si las ROMs están extraídas y no dentro de un .zip.
        • Si se ha descargado un conjunto de ROMs compatible con la versión usada.
        • Si se está usando una versión experimental de 86Box que requiere ROMs más recientes.

        Primer arranque de 86Box

        Al abrir 86Box veremos el gestor de máquinas virtuales.

        Desde ahí podremos:

        • Crear una máquina nueva.
        • Editar una máquina existente.
        • Arrancar una máquina.
        • Eliminar una configuración.
        • Duplicar configuraciones.
        • Gestionar discos e imágenes.

        En versiones actuales, 86Box abre directamente este gestor de máquinas, que sirve para administrar varias configuraciones emuladas.


        Máquina de ejemplo para la práctica

        Para esta práctica crearemos una máquina sencilla y estable:

        Máquina propuesta

        PC 486 con FreeDOS o MS-DOS

        Esta máquina es ideal para empezar porque permite trabajar con:

        • BIOS.
        • Disquetera.
        • Disco duro IDE.
        • FDISK.
        • Formateo.
        • Arranque desde disco.
        • Archivos AUTOEXEC.BAT y CONFIG.SYS.

        Configuración recomendada

        ElementoConfiguración
        Tipo de máquina486 compatible
        CPUIntel 486DX2/66
        RAM16 MB
        Tarjeta gráficaVGA / SVGA
        Tarjeta de sonidoSound Blaster 16
        Disco duroIDE de 512 MB
        Disquetera3.5” 1.44 MB
        CD-ROMOpcional
        Sistema operativoFreeDOS o MS-DOS
        RedNo necesaria

        Creación de la máquina virtual en 86Box

        Paso 1. Crear una nueva máquina

        Abrimos 86Box y seleccionamos la opción para crear una nueva máquina.

        Nombre recomendado:

        PC_486_DOS_Alumno

        También podemos usar un nombre más descriptivo:

        NombreAlumno_86Box_486_DOS

        Paso 2. Seleccionar la placa base

        En el apartado de máquina o placa base seleccionaremos una placa compatible con 486.

        El nombre exacto dependerá de las ROMs disponibles.

        Ejemplos posibles:

        AMI 486
        Award 486
        Socket 3
        486 PCI
        486 ISA/VLB/PCI

        No todos los modelos aparecerán en todas las instalaciones. Si una placa no aparece, normalmente significa que faltan ROMs o que no están bien colocadas.


        Paso 3. Seleccionar el procesador

        Elegimos una CPU de la familia 486.

        Configuración recomendada:

        Intel 486DX2/66

        Si no aparece exactamente esa opción, podemos usar otra parecida:

        Intel 486DX/33
        Intel 486DX2/50
        Intel 486DX2/66
        AMD 486DX2

        Paso 4. Configurar la memoria RAM

        Asignamos:

        16 MB

        Para DOS es una cantidad más que suficiente.

        No conviene asignar demasiada RAM porque perderíamos parte del sentido histórico de la práctica. Un PC 486 real normalmente trabajaba con cantidades mucho más modestas que un equipo actual.


        Paso 5. Configurar la tarjeta gráfica

        Elegimos una tarjeta sencilla y compatible.

        Opciones habituales:

        VGA
        SVGA
        Cirrus Logic
        S3 Trio
        Tseng ET4000

        Para DOS, una tarjeta VGA o SVGA básica es suficiente.


        Paso 6. Configurar la tarjeta de sonido

        Seleccionamos una tarjeta compatible con muchos juegos y programas de la época.

        Recomendación:

        Sound Blaster 16

        Valores típicos:

        ParámetroValor
        Dirección I/O220
        IRQ5 o 7
        DMA1
        High DMA5

        Más adelante estos valores se usarán en la variable BLASTER.


        Paso 7. Configurar la disquetera

        Añadimos una disquetera:

        3.5" 1.44 MB

        Esta unidad será la unidad A: dentro de DOS.


        Paso 8. Crear el disco duro virtual

        Creamos un disco duro nuevo.

        Tamaño recomendado:

        512 MB

        Nombre del archivo:

        discos/pc486_dos_512mb.img

        Tipo de conexión:

        IDE

        Este disco aparecerá como disco principal de la máquina.


        Paso 9. Configurar CD-ROM

        Este paso es opcional para la primera práctica, pero recomendable si queremos instalar software desde ISO.

        Configuración:

        CD-ROM IDE

        En DOS, para que el CD-ROM funcione, normalmente necesitaremos cargar un driver en CONFIG.SYS y MSCDEX.EXE en AUTOEXEC.BAT.


        Primera arrancada de la máquina

        Una vez creada la máquina, la arrancamos.

        Es normal que aparezcan mensajes como:

        CMOS checksum error
        No boot device
        Disk boot failure
        Insert system disk
        Press DEL to enter Setup

        Esto no significa que la práctica esté mal. Significa que la máquina todavía no tiene BIOS configurada ni sistema operativo instalado.


        Entrada en BIOS

        Paso 1. Pulsar la tecla de acceso

        Durante el arranque, pulsamos la tecla correspondiente para entrar en la BIOS.

        Las más habituales son:

        TeclaUso
        DEL / SuprBIOS AMI o Award
        F1Continuar o entrar en configuración
        F2Setup en algunas BIOS
        ESCMenú o salida
        F10Guardar y salir

        En muchas máquinas antiguas lo normal será:

        Supr / DEL

        Paso 2. Configurar fecha y hora

        Dentro de la BIOS, buscamos la pantalla principal.

        Ejemplo:

        Date: 05/04/1995
        Time: 12:00:00

        Podemos usar una fecha histórica para que la práctica tenga más contexto.


        Paso 3. Configurar la disquetera

        En el apartado de configuración básica o Standard CMOS Setup, configuramos:

        Drive A: 1.44M, 3.5 in.
        Drive B: None

        Paso 4. Configurar el disco duro

        Buscamos la configuración IDE.

        Configuramos:

        Primary Master: Auto
        Primary Slave: None
        Secondary Master: None
        Secondary Slave: None

        Si la BIOS tiene opción de autodetección:

        IDE HDD Auto Detection

        La ejecutamos y aceptamos el disco detectado.


        Paso 5. Configurar el orden de arranque

        Buscamos una opción parecida a:

        Boot Sequence
        Boot Order
        BIOS Features Setup

        Configuramos:

        A, C

        Esto significa:

        1. Primero intenta arrancar desde disquete.
        2. Si no hay disquete, arranca desde disco duro.

        También puede aparecer como:

        Floppy, HDD

        Paso 6. Guardar y salir

        Seleccionamos:

        Save & Exit Setup

        Confirmamos con:

        Y

        La máquina se reiniciará.


        Instalación de FreeDOS o MS-DOS

        Para clase recomiendo usar FreeDOS, porque es libre y evita problemas de licencias. Si se dispone de una licencia legítima de MS-DOS, también se puede usar.


        Paso 1. Montar el disquete o ISO de instalación

        Desde el menú de 86Box montamos la imagen correspondiente.

        Ejemplo con disquete:

        freedos_boot.img

        Ejemplo con CD-ROM:

        freedos.iso

        Paso 2. Arrancar desde el medio de instalación

        Arrancamos la máquina.

        Si todo está bien configurado, debería aparecer un instalador o un prompt parecido a:

        A:\>

        Paso 3. Crear partición con FDISK

        Ejecutamos:

        fdisk

        Seleccionamos las opciones:

        Create DOS partition
        Create Primary DOS Partition
        Use maximum available size
        Set partition active

        Después reiniciamos la máquina.


        Paso 4. Formatear el disco duro

        Volvemos a arrancar desde el disquete o medio de instalación.

        Ejecutamos:

        format c: /s

        El parámetro /s copia los archivos básicos del sistema para que el disco duro pueda arrancar.


        Paso 5. Arrancar desde el disco duro

        Apagamos la máquina.

        Quitamos el disquete o ISO de arranque.

        Arrancamos de nuevo.

        Si todo está correcto, veremos:

        C:\>

        La máquina ya arranca desde su propio disco duro virtual.


        Configuración básica de DOS

        Paso 1. Crear carpetas

        Ejecutamos:

        c:
        md DOS
        md DRIVERS
        md JUEGOS
        md UTIL
        md DOCUMENT

        Comprobamos con:

        dir

        Paso 2. Crear o editar AUTOEXEC.BAT

        El archivo AUTOEXEC.BAT se ejecuta automáticamente al arrancar DOS.

        Ejemplo básico:

        @ECHO OFF
        PROMPT $p$g
        PATH C:\DOS;C:\DRIVERS;C:\UTIL
        CLS
        ECHO Bienvenido al PC 486 emulado con 86Box

        Paso 3. Crear o editar CONFIG.SYS

        El archivo CONFIG.SYS carga controladores y configuración básica del sistema.

        Ejemplo:

        DEVICE=C:\DOS\HIMEM.SYS
        DOS=HIGH,UMB
        FILES=40
        BUFFERS=30
        LASTDRIVE=Z

        Paso 4. Reiniciar y comprobar

        Reiniciamos la máquina.

        Debe aparecer el mensaje:

        Bienvenido al PC 486 emulado con 86Box

        Configuración de CD-ROM en DOS

        Si hemos añadido un CD-ROM a la máquina, necesitaremos configurarlo.

        Paso 1. Copiar driver de CD-ROM

        Por ejemplo:

        OAKCDROM.SYS

        Lo copiamos a:

        C:\DRIVERS\CDROM\

        Paso 2. Modificar CONFIG.SYS

        Añadimos:

        DEVICE=C:\DRIVERS\CDROM\OAKCDROM.SYS /D:MSCD001

        Paso 3. Modificar AUTOEXEC.BAT

        Añadimos:

        C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D

        Paso 4. Reiniciar

        Tras reiniciar, el CD-ROM debería aparecer como:

        D:

        Configuración de Sound Blaster

        Si hemos configurado una Sound Blaster 16 en 86Box, podemos añadir la variable de entorno correspondiente.

        En AUTOEXEC.BAT:

        SET BLASTER=A220 I5 D1 H5 T6
        SET SOUND=C:\SB16

        Explicación:

        ParámetroSignificado
        A220Dirección base 220h
        I5IRQ 5
        D1DMA 1
        H5DMA alta 5
        T6Tipo Sound Blaster 16

        Si en 86Box hemos configurado otros valores, la variable BLASTER debe coincidir con ellos.


        Ejemplo de segunda máquina: Windows 98 SE

        Una vez terminada la máquina con DOS, podemos crear una segunda máquina más avanzada.

        Configuración propuesta

        ElementoConfiguración
        Tipo de máquinaSocket 7 / Pentium
        CPUPentium 133 o Pentium MMX
        RAM64 MB
        Disco duro2 GB
        Tarjeta gráficaS3 Trio / S3 ViRGE
        SonidoSound Blaster 16
        CD-ROMIDE
        Disquetera3.5” 1.44 MB
        Sistema operativoWindows 98 SE

        Pasos resumidos

        1. Crear una nueva máquina.
        2. Seleccionar placa Socket 7 o Pentium compatible.
        3. Asignar 64 MB de RAM.
        4. Crear disco duro de 2 GB.
        5. Añadir CD-ROM IDE.
        6. Montar disquete de arranque con soporte CD-ROM.
        7. Montar ISO de Windows 98 SE.
        8. Entrar en BIOS.
        9. Configurar disco, disquetera, CD-ROM y orden de arranque.
        10. Ejecutar fdisk.
        11. Crear partición primaria.
        12. Reiniciar.
        13. Formatear:
        format c: /s
        1. Entrar en la unidad del CD-ROM:
        D:
        1. Ejecutar:
        setup
        1. Seguir el instalador.
        2. Instalar drivers si son necesarios.
        3. Documentar el proceso.

        Problemas frecuentes

        Problema 1: 86Box dice que no hay ROMs utilizables

        Causa probable: las ROMs no están en la carpeta correcta o no están extraídas.

        Solución:

        • Revisar que existe la carpeta roms.
        • Colocarla junto al ejecutable si esa es la ruta usada.
        • Comprobar que las ROMs están descomprimidas.
        • Comprobar que el conjunto de ROMs corresponde a la versión de 86Box.

        Problema 2: no aparece la placa base que quiero usar

        Causa probable: faltan las ROMs de esa máquina concreta.

        Solución:

        • Probar otra placa base disponible.
        • Revisar el conjunto de ROMs.
        • Comprobar si la máquina elegida necesita ROMs específicas.

        Problema 3: aparece “CMOS checksum error”

        Causa: la BIOS todavía no tiene configuración guardada.

        Solución:

        1. Entrar en BIOS.
        2. Configurar fecha, hora, disquetera y disco duro.
        3. Guardar cambios.
        4. Reiniciar.

        Problema 4: el disco duro no aparece

        Causa: disco no creado, no conectado o no detectado por la BIOS.

        Solución:

        • Revisar la configuración IDE.
        • Entrar en BIOS.
        • Usar IDE HDD Auto Detection.
        • Guardar cambios.

        Problema 5: no arranca desde disquete

        Causa: orden de arranque incorrecto o imagen mal montada.

        Solución:

        • Configurar Boot Sequence como A, C.
        • Comprobar que la imagen de disquete está montada.
        • Comprobar que la imagen de disquete es arrancable.

        Problema 6: después de instalar DOS no arranca desde C:

        Causa: la partición no está activa o no se copiaron los archivos de sistema.

        Solución:

        Ejecutar de nuevo:

        fdisk

        Comprobar que la partición primaria está activa.

        Después:

        format c: /s

        Problema 7: el CD-ROM no aparece

        Causa: falta el driver de CD-ROM o MSCDEX.EXE.

        Solución:

        Revisar CONFIG.SYS:

        DEVICE=C:\DRIVERS\CDROM\OAKCDROM.SYS /D:MSCD001

        Revisar AUTOEXEC.BAT:

        C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D

        Problema 8: el sonido no funciona

        Causa: la configuración de Sound Blaster no coincide.

        Solución:

        Comprobar que los valores de 86Box coinciden con:

        SET BLASTER=A220 I5 D1 H5 T6

        Si en 86Box se ha configurado IRQ 7, habría que usar:

        SET BLASTER=A220 I7 D1 H5 T6

      1. PC-RETO  4: [Reto] – Implantación de un laboratorio histórico de ordenadores mediante emulación y virtualización

        PC-RETO 4: [Reto] – Implantación de un laboratorio histórico de ordenadores mediante emulación y virtualización


        Introducción

        En esta práctica el alumnado diseñará e implantará un pequeño laboratorio informático capaz de recrear distintas generaciones de ordenadores personales, desde equipos antiguos basados en MS-DOS y Windows 3.x / 95 / 98, hasta sistemas más modernos como Windows XP y Windows 7.

        Para ello se utilizarán dos tipos de herramientas:

        • Emulación, para recrear equipos antiguos con un hardware similar al de su época.
        • Virtualización, para instalar sistemas más recientes de forma rápida y controlada.

        El objetivo no es únicamente “ver sistemas antiguos”, sino analizar la evolución del hardware y del software, comprender las diferencias entre emular y virtualizar, y documentar técnicamente todo el proceso.


        Contexto de la práctica

        Una pequeña aula de tecnología quiere montar un laboratorio didáctico para mostrar a futuros estudiantes cómo ha evolucionado el PC a lo largo de varias décadas.

        El laboratorio debe permitir:

        • recrear distintas épocas de la informática personal,
        • instalar sistemas operativos representativos,
        • probar software y utilidades de cada momento,
        • comparar tecnologías,
        • documentar problemas de compatibilidad y configuración.

        El equipo técnico encargado de este trabajo sois vosotros.


        Objetivos

        Al finalizar esta práctica, el alumno deberá ser capaz de:

        • comprender la evolución del hardware del PC entre diferentes generaciones,
        • diferenciar entre emulación y virtualización,
        • instalar y configurar sistemas operativos antiguos y modernos en entornos virtuales,
        • seleccionar una configuración coherente para cada época,
        • documentar incidencias técnicas,
        • realizar pruebas de funcionamiento,
        • elaborar una memoria técnica del laboratorio montado.

        Resultados de aprendizaje que se trabajan

        Con esta práctica se trabajan, entre otros, aspectos relacionados con:

        • implantación de sistemas operativos,
        • administración básica de sistemas,
        • virtualización,
        • análisis de hardware,
        • documentación técnica,
        • resolución de incidencias,
        • planificación y validación de entornos informáticos.

        Materiales y herramientas necesarias

        Cada grupo o alumno deberá disponer de lo siguiente:

        • un ordenador anfitrión con recursos suficientes,
        • software de emulación: PCem o 86Box,
        • software de virtualización: VirtualBox,
        • imágenes ISO o disquetes de instalación de los sistemas operativos a utilizar,
        • utilidades o programas representativos de cada época,
        • carpeta de trabajo para guardar capturas, configuraciones y documentación.

        Sistemas y generaciones propuestas

        Se recomienda recrear al menos cuatro generaciones diferentes. Como referencia, se propone esta selección:

        GeneraciónTipo de entornoSistema propuesto
        1990EmulaciónMS-DOS 5.0 + Windows 3.0 o 3.1
        1995EmulaciónWindows 95
        2000EmulaciónWindows 98 SE
        2005VirtualizaciónWindows XP
        2010VirtualizaciónWindows 7

        El profesor podrá ajustar esta lista según el material disponible.


        Desarrollo de la práctica


        Paso 1. Crear la estructura del proyecto

        Antes de empezar, cada alumno o grupo deberá crear una carpeta principal para organizar todo el trabajo.

        Estructura recomendada

        laboratorio-pc-retro/
        ├── 01-documentacion/
        ├── 02-isos/
        ├── 03-maquinas-emuladas/
        ├── 04-maquinas-virtuales/
        ├── 05-capturas/
        ├── 06-pruebas/
        └── 07-memoria-final/

        Tarea

        Crea esta estructura y guarda una captura del árbol de directorios o del explorador de archivos.

        Evidencia

        • Captura de la estructura creada.

        Paso 2. Investigar las generaciones de PC seleccionadas

        Antes de crear máquinas, el alumno deberá investigar las características principales de cada época.

        Para cada generación, anota:

        • microprocesador representativo,
        • cantidad de RAM habitual,
        • tipo de almacenamiento,
        • tarjeta gráfica típica,
        • tarjeta de sonido representativa,
        • sistema operativo habitual,
        • tipo de software o uso principal.

        Ejemplo

        • 1995: Pentium 100/133, 16 MB RAM, disco duro de 1 GB, Sound Blaster 16, Windows 95, juegos en CD-ROM y aplicaciones multimedia.

        Tarea

        Completa una tabla comparativa con al menos 4 generaciones.

        Evidencia

        • Tabla comparativa incluida en la memoria.
        • Captura o documento con la investigación realizada.

        Paso 3. Instalar y configurar el software necesario

        3.1 Instalar el emulador

        Instala PCem o 86Box en el equipo anfitrión.

        3.2 Instalar el virtualizador

        Instala VirtualBox.

        3.3 Comprobar funcionamiento

        Verifica que ambos programas arrancan correctamente.

        Tarea

        Instala ambos entornos y documenta:

        • versión utilizada,
        • sistema operativo anfitrión,
        • posibles problemas detectados,
        • solución aplicada, si ha sido necesaria.

        Evidencia

        • Capturas de ambos programas abiertos.
        • Anotación técnica de instalación.

        Paso 4. Crear la primera máquina emulada: entorno de 1990

        En esta fase se creará una máquina que represente un PC de principios de los 90.

        Configuración orientativa

        • CPU: 386DX-33
        • RAM: 4 MB
        • Gráfica: VGA
        • Sonido: Sound Blaster Pro
        • Disco duro: 80–120 MB
        • Disquetera: 3,5″
        • Sistema: MS-DOS 5.0
        • Opcional: Windows 3.0 o 3.1

        Tareas

        1. Crear la máquina en PCem o 86Box.
        2. Configurar CPU, RAM, disco y periféricos.
        3. Instalar MS-DOS.
        4. Instalar, si se desea, Windows 3.x.
        5. Comprobar que el sistema arranca correctamente.

        Qué debes documentar

        • configuración exacta elegida,
        • motivo de esa elección,
        • proceso de instalación,
        • dificultades encontradas.

        Evidencias

        • Capturas de la configuración de la máquina,
        • captura del sistema arrancado,
        • captura del sistema operativo funcionando.

        Paso 5. Crear la segunda máquina emulada: entorno de 1995

        Ahora se recreará un PC multimedia típico de mediados de los 90.

        Configuración orientativa

        • CPU: Pentium 100 o 133
        • RAM: 16 MB
        • Disco duro: 850 MB – 1.6 GB
        • Gráfica: SVGA PCI
        • Sonido: Sound Blaster 16 o AWE32
        • CD-ROM: 4x u 8x
        • Sistema: Windows 95

        Tareas

        1. Crear una nueva máquina emulada.
        2. Configurar el hardware anterior.
        3. Instalar Windows 95.
        4. Verificar si el sonido, el vídeo y el CD-ROM funcionan correctamente.
        5. Instalar algún programa o utilidad sencilla de la época.

        Evidencias

        • Capturas del asistente de instalación,
        • escritorio final de Windows 95,
        • captura de “Mi PC” o equivalente mostrando unidades,
        • prueba de ejecución de un programa.

        Paso 6. Crear la tercera máquina emulada: entorno de 2000

        En esta fase se montará un equipo de finales de los 90 o principios de los 2000.

        Configuración orientativa

        • CPU: Pentium II o Pentium III
        • RAM: 64–128 MB
        • Disco duro: 10–20 GB
        • Gráfica: Voodoo3 o GeForce 2
        • Sonido: Sound Blaster Live!
        • Sistema: Windows 98 SE

        Tareas

        1. Crear la máquina.
        2. Configurar el hardware.
        3. Instalar Windows 98 SE.
        4. Ajustar resolución y sonido.
        5. Probar una aplicación o un juego sencillo.

        Evidencias

        • Capturas del sistema ya instalado,
        • propiedades del sistema,
        • evidencia de la gráfica o del sonido configurados,
        • prueba funcional con software.

        Paso 7. Crear la cuarta máquina: entorno 2005 mediante virtualización

        Ahora se pasará a usar VirtualBox para montar un sistema más moderno.

        Configuración orientativa

        • Sistema: Windows XP
        • RAM: 1 GB
        • Disco duro virtual: 20–40 GB
        • Red: NAT o red interna
        • Audio: habilitado si es posible

        Tareas

        1. Crear una nueva máquina virtual.
        2. Asignar memoria y disco.
        3. Montar la ISO de instalación.
        4. Instalar Windows XP.
        5. Configurar red, resolución y carpetas compartidas si es posible.
        6. Probar software compatible.

        Evidencias

        • Capturas de la configuración de la VM,
        • instalación de XP,
        • escritorio final,
        • información del sistema.

        Paso 8. Crear la quinta máquina: entorno 2010 mediante virtualización

        Configuración orientativa

        • Sistema: Windows 7
        • RAM: 2–4 GB
        • Disco virtual: 30–50 GB

        Tareas

        1. Crear una nueva VM.
        2. Instalar Windows 7.
        3. Comprobar funcionamiento general.
        4. Comparar facilidad de instalación frente a sistemas anteriores.

        Evidencias

        • Capturas del proceso,
        • sistema operativo final,
        • tabla comparativa de instalación.

        Paso 9. Comparar emulación y virtualización

        Esta fase es obligatoria, ya que da sentido técnico al proyecto.

        Debes analizar:

        • qué es más fácil de instalar,
        • qué ofrece mayor fidelidad histórica,
        • qué permite mejor compatibilidad con sistemas antiguos,
        • qué consume más recursos,
        • qué entorno es más cómodo para practicar,
        • qué problemas aparecen en cada caso.

        Tarea

        Redacta una comparativa entre:

        • PCem / 86Box
        • VirtualBox

        Preguntas orientativas

        • ¿Por qué no es recomendable instalar un Windows 95 antiguo solo con VirtualBox si se busca realismo?
        • ¿Por qué un Windows XP es más adecuado en VirtualBox que en un emulador de hardware muy antiguo?
        • ¿Qué ventajas tiene cada enfoque?

        Evidencias

        • Tabla comparativa,
        • conclusiones razonadas.

        Paso 10. Realizar pruebas funcionales

        Cada máquina debe validarse con una pequeña batería de pruebas.

        Pruebas mínimas recomendadas

        • arranque correcto,
        • acceso al disco,
        • funcionamiento del sistema gráfico,
        • funcionamiento del sonido,
        • apertura de una aplicación,
        • estabilidad general.

        Tabla de ejemplo

        MáquinaArrancaVídeoSonidoAplicacionesObservaciones
        1990Instalación correcta
        1995NoProblemas con el sonido
        2000Funcionamiento estable

        Evidencias

        • tabla de pruebas,
        • capturas de evidencias,
        • explicación de errores detectados.

        Paso 11. Registrar incidencias técnicas

        Durante toda la práctica se deberá mantener un pequeño registro de incidencias.

        Para cada incidencia, anota:

        • descripción del problema,
        • en qué momento ocurrió,
        • posible causa,
        • solución aplicada,
        • resultado final.

        Ejemplos

        • La ISO no arrancaba en la máquina virtual.
        • El sonido no funcionaba correctamente en el sistema emulado.
        • El disco virtual era demasiado pequeño.
        • La resolución de pantalla no era correcta.
        • El sistema no detectaba la unidad de CD.

        Evidencias

        • tabla de incidencias incluida en la memoria final.

        Paso 12. Elaborar una conclusión técnica

        El alumno deberá redactar una conclusión personal y técnica sobre el trabajo realizado.

        La conclusión debe responder a cuestiones como:

        • qué generación fue más fácil de montar,
        • cuál resultó más problemática,
        • qué diferencias hay entre el hardware antiguo y el moderno,
        • qué valor didáctico tiene este laboratorio,
        • qué mejoras se podrían incorporar en el futuro.

        Entregables

        Cada alumno o grupo entregará:

        1. Carpeta del proyecto

        Con la organización del trabajo, capturas y documentación.

        2. Memoria técnica en PDF

        Debe incluir como mínimo:

        • portada,
        • índice,
        • introducción,
        • objetivos,
        • herramientas utilizadas,
        • explicación de cada máquina creada,
        • capturas,
        • incidencias,
        • pruebas realizadas,
        • comparativa entre emulación y virtualización,
        • conclusiones.

        3. Tabla resumen de máquinas

        Con la configuración de cada una.

        4. Evidencias gráficas

        Capturas claras del proceso y del resultado final.

        Algunos ejemplos de configuraciones

        PC compatibles x86, pensados para MS-DOS, Windows 3.x, Windows 95 y Windows 98, ideales para emular en 86Box.

        Años aproximadosTipo de PCConfiguración representativaSistema recomendadoJuegos recomendados
        1981-1984PC XT / 8088Intel 8088 a 4,77 MHz, 256-640 KB RAM, CGA o Hercules, disquetera 5,25”, sin disco duro o HDD pequeño de 10 MBPC-DOS / MS-DOS 2.xZork, Microsoft Flight Simulator 1.0, Alley Cat, King’s Quest, Digger
        1984-1987PC AT / 286Intel 80286 a 6-12 MHz, 640 KB RAM, EGA, HDD 20-40 MB, disquetera 5,25” y 3,5” opcionalMS-DOS 3.3King’s Quest II, Leisure Suit Larry, Test Drive, Police Quest, Maniac Mansion
        1987-1990386 SX básicoIntel 386SX a 16-25 MHz, 1-2 MB RAM, VGA básica, HDD 40 MB, disquetera 3,5”MS-DOS 5.0 / Windows 3.0Prince of Persia, SimCity, Loom, The Secret of Monkey Island, Commander Keen
        1989-1992386 DX avanzadoIntel 386DX a 25-33 MHz, 2-4 MB RAM, VGA, HDD 80-120 MB, Sound Blaster 1.5/Pro opcionalMS-DOS 5.0 / Windows 3.0Monkey Island 2, Civilization, Wing Commander, Wolfenstein 3D, Indiana Jones and the Fate of Atlantis
        1992-1994486 SX / DXIntel 486SX/486DX a 25-50 MHz, 4-8 MB RAM, VGA/SVGA, HDD 120-250 MB, Sound Blaster ProMS-DOS 6.22 / Windows 3.1Dune II, Alone in the Dark, X-Wing, Ultima VII, Star Wars: Dark Forces
        1993-1995486 DX2/66Intel 486DX2 a 66 MHz, 8-16 MB RAM, SVGA VLB/PCI, HDD 250-540 MB, Sound Blaster 16, CD-ROM 2xMS-DOS 6.22 + Windows 3.11Doom, Doom II, Day of the Tentacle, Sam & Max Hit the Road, Theme Park, Warcraft
        1994-1996486 DX4 / Pentium inicial486DX4/100 o Pentium 60/75/90, 16 MB RAM, SVGA PCI, HDD 540 MB-1 GB, Sound Blaster 16/AWE32, CD-ROM 4xMS-DOS 6.22 + Windows 95Command & Conquer, Warcraft II, Descent, Heretic, Full Throttle, The Dig
        1995-1997Pentium 100/133Intel Pentium 100-133 MHz, 16-32 MB RAM, SVGA PCI, HDD 1-2 GB, Sound Blaster AWE32/AWE64, CD-ROM 4x/8xWindows 95Duke Nukem 3D, Quake, Diablo, Tomb Raider, Broken Sword, Need for Speed
        1996-1998Pentium MMXPentium MMX 166-233 MHz, 32-64 MB RAM, SVGA, HDD 2-4 GB, Sound Blaster AWE64, CD-ROM 8x/16x, aceleradora 3D opcionalWindows 95 OSR2 / Windows 98Age of Empires, Fallout, Carmageddon, Grand Theft Auto, StarCraft, Blade Runner
        1997-1999Pentium II con 3DfxPentium II 233-400 MHz, 64-128 MB RAM, gráfica 2D PCI/AGP + 3Dfx Voodoo/Voodoo2, HDD 4-8 GB, CD-ROM 24xWindows 98Half-Life, Quake II, Unreal, Tomb Raider II, Need for Speed III, SiN
        1998-2000Pentium III / AMD K6-2Pentium III 450-600 MHz o AMD K6-2 400-500 MHz, 128 MB RAM, NVIDIA Riva TNT2 / Voodoo3 / GeForce 256, HDD 8-20 GBWindows 98 SEAge of Empires II, Unreal Tournament, Quake III Arena, System Shock 2, Baldur’s Gate, Heroes III

        Recomendación práctica para 86Box

        Para no volverte loco creando muchas máquinas, yo haría estas 5 configuraciones base:

        PerfilConfiguración sugeridaSistemaIdeal para
        PC XT clásico8088, 640 KB RAM, CGA, disquetera 5,25”MS-DOS 2.x / 3.xJuegos muy antiguos de principios de los 80
        PC 286 EGA286 a 12 MHz, 1 MB RAM, EGA, HDD 20-40 MBMS-DOS 3.3Aventuras Sierra, Lucasfilm antiguas, juegos EGA
        PC 386 VGA386DX 33 MHz, 4 MB RAM, VGA, Sound Blaster ProMS-DOS 5.0Monkey Island, Civilization, Wolfenstein 3D
        PC 486 DOS Gaming486DX2/66, 16 MB RAM, SVGA, Sound Blaster 16, CD-ROMMS-DOS 6.22 + Windows 3.11Doom, Doom II, Day of the Tentacle, Sam & Max
        Pentium Windows 98Pentium II 300, 128 MB RAM, S3 Trio64/ViRGE + 3Dfx Voodoo, Sound Blaster 16/AWE32Windows 98 SEHalf-Life, Quake II, Unreal, Age of Empires II

        Consejo

        Para juegos tipo Monkey Island, Indiana Jones, Doom, Warcraft, Command & Conquer y aventuras gráficas, la máquina más equilibrada es:

        PiezaConfiguración
        CPU486DX2/66 o 486DX4/100
        RAM16 MB
        GráficaSVGA compatible, por ejemplo S3 Trio64
        SonidoSound Blaster 16
        Disco duro500 MB – 1 GB
        CD-ROMIDE 2x o 4x
        SistemaMS-DOS 6.22 + Windows 3.11

        Esa máquina te sirve para muchísimos juegos DOS sin meterte todavía en los problemas típicos de Windows 98, DirectX, 3Dfx y drivers.

      2. PC-RETRO 5: IBM PC 5150 / IBM PC XT viajando al origen del PC moderno

        PC-RETRO 5: IBM PC 5150 / IBM PC XT viajando al origen del PC moderno

        Cuando hoy hablamos de un “PC”, normalmente pensamos en un ordenador con Windows, Linux, conexión a Internet, discos SSD, varios gigabytes de memoria RAM y una potencia que hace unas décadas habría sido impensable. Sin embargo, el concepto de PC compatible tiene un origen mucho más humilde y, al mismo tiempo, enormemente importante: el IBM PC 5150 y su evolución, el IBM PC XT.

        En esta práctica vamos a viajar al comienzo de la informática personal moderna. No se trata únicamente de “probar un ordenador antiguo”, sino de entender cómo funcionaban los primeros PCs, cómo arrancaban, cómo se gestionaban los discos, qué papel tenía la BIOS y cómo se trabajaba con sistemas operativos como PC DOS o MS-DOS.

        Este tipo de práctica es especialmente interesante porque nos permite ver, de forma muy clara, la base sobre la que se construyó gran parte de la informática actual.


        ¿Qué fue el IBM PC 5150?

        El IBM PC 5150 fue presentado por IBM en 1981 y se convirtió en uno de los ordenadores más influyentes de la historia. Aunque no fue el primer ordenador personal, sí fue el que ayudó a establecer el estándar de lo que durante años se conocería como PC compatible.

        Su arquitectura era relativamente abierta en comparación con otros sistemas de la época. Esto permitió que otras empresas fabricaran componentes, tarjetas de expansión, periféricos y, con el tiempo, ordenadores compatibles con el diseño original de IBM.

        Esta decisión tuvo una consecuencia enorme: el ecosistema del PC creció rápidamente y terminó convirtiéndose en el modelo dominante en oficinas, centros educativos, empresas y hogares.



        ¿Por qué emular un IBM PC o un IBM PC XT?

        A primera vista, emular un ordenador de los años 80 puede parecer solo una actividad nostálgica. Pero en realidad es una práctica muy potente desde el punto de vista educativo.

        Con una máquina moderna, muchos procesos quedan ocultos. El sistema operativo arranca automáticamente, los discos se detectan solos, los controladores se instalan en segundo plano y el usuario apenas ve qué ocurre por debajo.

        En cambio, al trabajar con un IBM PC o un PC XT, todo es mucho más visible:

        • la BIOS tiene un papel fundamental;
        • el arranque se entiende paso a paso;
        • el sistema operativo se carga desde disquete o disco duro;
        • las unidades tienen letras como A:, B: y C:;
        • los comandos se escriben manualmente;
        • los recursos del sistema son muy limitados;
        • cada componente de hardware debe estar bien configurado.

        Esta sencillez aparente nos ayuda a comprender conceptos que siguen siendo importantes hoy en día.

        Configuración 86Box


        Arranque sin sistema operativo (BASIC)

        Instalar MS-DOS 3.3

        Con la máquina apagada o desde el menú de 86Box:

        1. Ve a Media.
        2. Entra en Floppy 1.
        3. Selecciona Existing image.
        4. Carga una imagen .img o .ima de MS-DOS. (Es importante que el medio coincida, en este caso discos de 5 1/4 de 360)

        Si todo va bien, ya no entrará en BASIC, sino que aparecerá algo como:

        Starting MS-DOS...
        A:\>

        Primeros comandos útiles en DOS

        Cuando llegues a:

        A:\>

        Prueba:

        DIR

        Muestra los archivos del disquete.

        VER

        Muestra la versión de DOS.

        DATE

        Configura la fecha.

        TIME

        Configura la hora.

        CLS

        Limpia la pantalla.

        Instalando MS-DOS en el disco duro

        Formatea el disco duro

        Cuando vuelvas a estar en:

        A:\>

        escribe:

        FORMAT C: /S

        La opción /S copia los archivos de sistema al disco duro para que pueda arrancar.

        Formateando el disco duro c:

        Te pedirá confirmación:

        WARNING, ALL DATA ON NON-REMOVABLE DISK DRIVE C: WILL BE LOST!
        Proceed with Format (Y/N)?

        Responde:

        Y

        Cuando termine, puedes poner una etiqueta al disco, por ejemplo:

        DOS

        Prueba el disco duro

        Ahora escribe:

        C:

        Luego:

        DIR

        Deberías ver algo parecido a:

        COMMAND  COM
        ```

        O en algunas versiones:

        ```text
        IO SYS
        MSDOS SYS
        COMMAND COM

        Si ves esos archivos, el disco está preparado.


        Arrancar desde el disco duro

        Ahora puedes quitar el disquete de la unidad A: y reiniciar.

        Si todo está bien, debería arrancar directamente desde el disco duro y aparecer:


        Pruebas

        Probamos el juego de Cat Alley

      3. PC-RETRO 6: IBM PS/ValuePoint: el PC con el que IBM quiso volver al mundo real

        PC-RETRO 6: IBM PS/ValuePoint: el PC con el que IBM quiso volver al mundo real

        🎧 Audio del tema
        Escucha este breve audio para repasar las ideas principales este proyecto.


        Dentro del proyecto de PC retro vamos a trabajar con una máquina muy interesante: el IBM PS/ValuePoint. No es tan mítico como un IBM PC XT, ni tan recordado como los PS/2, pero representa un momento muy importante de la historia del PC: el momento en el que IBM tuvo que aceptar que el mercado ya no giraba solo alrededor de sus estándares propietarios.

        El IBM PS/ValuePoint fue una familia de ordenadores lanzada a comienzos de los años 90. Su objetivo era claro: ofrecer equipos IBM más competitivos, más parecidos a los PC compatibles del mercado y menos cerrados que la gama PS/2. La línea PS/ValuePoint apareció alrededor de 1992 y estuvo activa hasta mediados de los años 90, antes de ser sustituida por otras familias como IBM PC Series.

        Para nuestro proyecto retro es una máquina ideal porque nos coloca justo en la época dorada del 486, de MS-DOS, de Windows 3.1, de los primeros entornos multimedia y de juegos como Doom, Monkey Island 2, Alone in the Dark, SimCity 2000, Wolfenstein 3D o Indiana Jones and the Fate of Atlantis.


        ¿Qué era el IBM PS/ValuePoint?

        El IBM PS/ValuePoint fue una gama de ordenadores personales de IBM orientada a empresas, educación y usuarios que querían un PC fiable sin pagar el precio ni asumir las limitaciones de algunas decisiones propietarias de IBM.

        Venía de una época complicada para IBM. La empresa había creado el estándar PC original, pero después intentó recuperar control con la gama PS/2, que utilizaba tecnologías como el bus Micro Channel Architecture, más cerrado y menos compatible con las tarjetas habituales del mercado. El problema es que el mundo del PC compatible ya iba por libre: placas base clónicas, tarjetas ISA, discos IDE, tarjetas VGA/SVGA y componentes más económicos.

        El PS/ValuePoint fue una respuesta a esa situación. Era un IBM, sí, pero mucho más cercano al PC estándar que podía montar cualquier fabricante. En lugar de apostar por un ecosistema cerrado, estos equipos usaban componentes más comunes en el mercado, como buses ISA/VLB/PCI según modelo, discos IDE y tarjetas de expansión más convencionales.

        Dicho de forma sencilla: el PS/ValuePoint fue IBM bajando a la tierra del PC compatible.


        Modelos y formatos

        La familia PS/ValuePoint tuvo varios formatos físicos. Entre los más representativos estaban:

        FormatoEjemplo de tipoDescripción
        Space saving desktop6382 /SCaja horizontal compacta, menos ranuras y bahías
        Desktop6384 /DSobremesa horizontal más grande
        Mini Tower6387 /TTorre pequeña, más ampliable

        Algunos documentos de mantenimiento de IBM mencionan modelos como 425SX, 433SX, 433DX, 466DX2 y variantes en formato /S, /D y /T. Estos nombres suelen indicar el tipo de procesador: por ejemplo, un 466DX2 hace referencia a un 486DX2 a 66 MHz.

        Para emulación en 86Box, una configuración muy interesante es un IBM PS/ValuePoint 433DX o 466DX2, porque representa muy bien un PC de mediados de los 90 sin irnos todavía a la era Pentium.


        Especificaciones típicas

        Las configuraciones variaban mucho según modelo, pero una máquina representativa podía tener algo parecido a esto:

        ComponenteConfiguración típica
        ProcesadorIntel 486SX, 486DX, 486DX2 o incluso DX4 en algunos modelos
        Frecuencia25, 33, 50, 66 o 100 MHz según versión
        Memoria RAM4 MB, 8 MB, 16 MB o más
        Disco duroIDE, normalmente entre 120 MB y 500 MB en configuraciones habituales
        Disquetera3.5” de 1.44 MB
        VídeoVGA/SVGA, a menudo integrado en placa
        SonidoNo siempre incluido; se podía añadir Sound Blaster u otra ISA
        Sistema operativoPC DOS, MS-DOS, Windows 3.1, OS/2 o posteriormente Windows 95

        Algunas referencias de IBM para modelos ValuePoint muestran configuraciones con procesadores 486SX-25, 486DX-33, 486DX2-50 y 486DX2-66, memoria de 4 u 8 MB, discos de 120 MB o 170 MB y PC DOS 5.02 con Windows 3.1 en ciertos modelos.


        ¿Por qué es interesante para un proyecto retro?

        El IBM PS/ValuePoint es perfecto para un proyecto de PC retro por varias razones.

        Primero, porque representa una época muy concreta: el salto desde los PC puramente de oficina hacia los PC multimedia. Es la etapa en la que todavía se trabaja mucho con MS-DOS, pero Windows empieza a ganar protagonismo.

        Segundo, porque es una máquina suficientemente potente para ejecutar muchos juegos clásicos de DOS, pero no tan moderna como para perder la sensación retro. Un 486DX2 a 66 MHz sigue teniendo limitaciones, y eso es parte de la gracia.

        Tercero, porque permite explicar conceptos históricos muy útiles:

        • Diferencias entre IBM PC, PS/2 y PS/ValuePoint.
        • Evolución de ISA, VLB y PCI.
        • Importancia del disco IDE.
        • Papel de MS-DOS y Windows 3.1.
        • Primeros pasos del PC multimedia.
        • Tarjetas de sonido compatibles Sound Blaster.
        • Configuración manual de memoria convencional, EMS y XMS.

        Y cuarto, porque en 86Box podemos recrearlo sin necesidad de tener el hardware real.

        Programas recomendados

        Además de juegos, podemos instalar software de la época para darle más sentido al proyecto.

        ProgramaUso
        MS-DOS 6.22Sistema base clásico
        Windows 3.11Entorno gráfico de la época
        Norton CommanderGestión de archivos
        Microsoft WorksOfimática ligera
        WordPerfectProcesador de textos clásico
        PaintbrushDibujo básico en Windows
        WinZip antiguoCompresión de archivos
        QBasicProgramación básica en DOS
        Turbo PascalProgramación clásica
        Borland C++Desarrollo en C/C++
        Doom SetupConfiguración de sonido, teclado y vídeo

        Configurar un IBM PS/ValuePoint en 86Box

        En esta práctica vamos a crear una máquina virtual en 86Box que simule un IBM PS/ValuePoint basado en 486. Después prepararemos el disco duro, instalaremos MS-DOS, añadiremos soporte para CD-ROM, configuraremos una tarjeta de sonido y dejaremos el sistema listo para instalar juegos y programas clásicos.


        Material necesario

        Antes de empezar necesitamos:

        ElementoUso
        86Box instaladoEmulador de PC clásico
        ROMs de 86BoxNecesarias para arrancar las máquinas
        Imagen de disquete de MS-DOS 6.22Instalación del sistema operativo
        Imagen ISO o carpeta con juegos/programasSoftware para instalar
        Imagen de drivers de Sound BlasterPara configurar sonido
        Imagen o driver de CD-ROMPor ejemplo OAKCDROM.SYS
        Tiempo y pacienciaMuy necesario en informática retro

        Importante: 86Box emula hardware de forma más realista que otros emuladores. Eso significa que a veces hay que configurar BIOS, discos, controladoras y drivers como se hacía en los años 90.


        Configuración recomendada

        Para empezar, recomiendo una configuración equilibrada:

        ApartadoValor recomendado
        MáquinaIBM PS/ValuePoint 433DX o 466DX2, si está disponible
        CPUIntel 486DX2 a 66 MHz
        RAM16 MB
        VídeoSVGA integrado o compatible
        Disco duroIDE de 504 MB
        Disquetera3.5” 1.44 MB
        CD-ROMIDE ATAPI
        SonidoSound Blaster 16 ISA
        Sistema operativoMS-DOS 6.22 + Windows 3.11
        AlternativaWindows 95 si se quiere probar algo más moderno

        86Box sigue actualizándose y ha recibido correcciones relacionadas con modelos IBM PS/ValuePoint, por ejemplo en versiones recientes se mencionan ajustes sobre el vídeo integrado del IBM PS/ValuePoint 433DX/Si.


        Paso 1. Crear una nueva máquina en 86Box

        Abrimos 86Box y creamos una nueva configuración.

        1. Abrimos 86Box.
        2. Creamos una nueva máquina.
        3. Elegimos una categoría de equipos 486.
        4. Buscamos un modelo relacionado con IBM PS/ValuePoint.
        5. Seleccionamos un modelo como:
          • IBM PS/ValuePoint 433DX
          • IBM PS/ValuePoint 466DX2
          • IBM PS/ValuePoint P60, si queremos probar una configuración más moderna tipo Pentium.

        Para este post recomiendo trabajar con un 486DX2, porque es más representativo de la época DOS/Windows 3.1.


        Paso 2. Configurar el procesador

        En la sección de CPU seleccionamos:

        OpciónValor
        ProcesadorIntel 486DX2
        Velocidad66 MHz
        FPUIntegrada, si usamos DX/DX2
        Modo dinámicoActivado si 86Box lo permite

        Un 486DX2 a 66 MHz es una configuración excelente para juegos de 1992-1994.


        Paso 3. Configurar la memoria RAM

        Configuramos la memoria en:

        UsoRAM recomendada
        Solo MS-DOS4 MB u 8 MB
        MS-DOS + Windows 3.18 MB o 16 MB
        Windows 9516 MB o 32 MB

        Para esta práctica usaremos:

        16 MB de RAM

        Es suficiente para DOS, Windows 3.11 y una buena cantidad de juegos.


        Paso 4. Configurar el disco duro

        Creamos un disco duro IDE.

        Recomendación:

        ParámetroValor
        TipoIDE
        Tamaño504 MB
        FormatoImagen nueva
        UsoSistema operativo + juegos

        ¿Por qué 504 MB? Porque muchos equipos antiguos tenían limitaciones de BIOS con discos grandes. Para evitar problemas, es mejor empezar con un disco pequeño y compatible. En conversaciones de usuarios reales sobre PS/ValuePoint se mencionan límites prácticos cercanos a 500 MB en algunos modelos 6382.


        Paso 5. Añadir disquetera

        Configuramos una disquetera:

        OpciónValor
        Unidad A:3.5” 1.44 MB
        Imagen inicialDisco 1 de MS-DOS 6.22

        Esto nos permitirá arrancar el instalador de MS-DOS.


        Paso 6. Añadir CD-ROM

        Añadimos una unidad de CD-ROM IDE/ATAPI.

        OpciónValor recomendado
        TipoIDE ATAPI CD-ROM
        CanalSecundario maestro, si está disponible
        UsoInstalar juegos, drivers y Windows

        Si el CD-ROM no aparece dentro de DOS, no es un fallo raro. En MS-DOS hay que cargar un driver en CONFIG.SYS y después MSCDEX.EXE en AUTOEXEC.BAT.


        Paso 7. Configurar tarjeta de sonido

        Añadimos una tarjeta de sonido compatible.

        Recomendación:

        OpciónValor
        TarjetaSound Blaster 16
        Puerto220
        IRQ5 o 7
        DMA1
        High DMA5
        MPU-401330

        Configuración típica:

        BLASTER=A220 I5 D1 H5 P330 T6

        Esta configuración será importante para juegos como Doom, Duke Nukem II o Monkey Island 2.


        Paso 8. Primer arranque

        Montamos el primer disquete de MS-DOS 6.22 y arrancamos la máquina.

        Si todo va bien, aparecerá el instalador de MS-DOS.

        Si aparece un error del tipo “no boot disk” o “no system disk”, revisamos:

        • Que el disquete esté montado en la unidad A:
        • Que el orden de arranque permita arrancar desde disquete.
        • Que la imagen del disquete sea arrancable.
        • Que la máquina tenga una disquetera configurada.

        Crear partición con FDISK

        Si el disco está vacío, MS-DOS necesitará crear una partición.

        Desde el disquete de arranque podemos ejecutar:

        FDISK

        Dentro de FDISK:

        1. Crear partición primaria DOS.
        2. Usar todo el tamaño del disco.
        3. Marcar la partición como activa.
        4. Salir de FDISK.
        5. Reiniciar la máquina.

        Importante: después de crear la partición hay que reiniciar. Si no reiniciamos, DOS puede no reconocer correctamente el disco.


        Formatear el disco duro

        Después de reiniciar con el disquete de DOS, ejecutamos:

        FORMAT C: /S

        Esto formatea el disco C: y copia los archivos básicos del sistema para que pueda arrancar.

        Cuando termine, podemos poner una etiqueta al disco, por ejemplo:

        VALUEPOINT

        Instalar MS-DOS

        Ejecutamos el instalador desde el disquete:

        A:
        SETUP

        Seguimos los pasos del instalador e iremos cambiando los disquetes cuando nos lo pida.

        Al finalizar, quitamos el disquete y reiniciamos.

        Si todo ha ido bien, el sistema arrancará desde el disco duro C:.

        Configurar el CD-ROM en MS-DOS

        Para que MS-DOS detecte el CD-ROM necesitamos un driver. Uno de los más habituales es:

        OAKCDROM.SYS

        Podemos copiarlo a una carpeta, por ejemplo:

        C:\CDROM

        Creamos la carpeta:

        MD C:\CDROM

        Copiamos el driver:

        COPY A:\OAKCDROM.SYS C:\CDROM

        Editamos CONFIG.SYS:

        EDIT C:\CONFIG.SYS

        Añadimos:

        DEVICE=C:\CDROM\OAKCDROM.SYS /D:MSCD001

        Ahora editamos AUTOEXEC.BAT:

        EDIT C:\AUTOEXEC.BAT

        Añadimos:

        C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D

        Reiniciamos.

        Si todo va bien, el CD-ROM aparecerá como unidad D:.

        Configurar memoria para juegos

        Muchos juegos de DOS necesitan memoria convencional libre. Podemos mejorar la configuración usando HIMEM.SYS y EMM386.EXE.

        Ejemplo de CONFIG.SYS:

        DEVICE=C:\DOS\HIMEM.SYS
        DEVICE=C:\DOS\EMM386.EXE RAM
        DOS=HIGH,UMB
        FILES=40
        BUFFERS=30
        DEVICEHIGH=C:\CDROM\OAKCDROM.SYS /D:MSCD001

        Ejemplo de AUTOEXEC.BAT:

        @ECHO OFF
        PROMPT $P$G
        PATH C:\DOS;C:\WINDOWS
        SET TEMP=C:\TEMP
        SET BLASTER=A220 I5 D1 H5 P330 T6
        LH C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D

        Creamos la carpeta temporal:

        MD C:\TEMP

        Con esto tendremos un DOS más preparado para juegos.

        Ratón en MS- DOS con 86Box

        Con la máquina apagada, entra en la configuración de 86Box y busca la parte de Input / Mouse.

        Para un 486 tipo IBM PS/ValuePoint, lo más recomendable es probar:

        OpciónValor recomendado
        MousePS/2 Mouse
        TipoStandard / Microsoft compatible

        Si el equipo emulado no acepta PS/2, prueba con:

        OpciónValor alternativo
        MouseSerial Mouse
        PuertoCOM1

        Pero primero probaría PS/2 Mouse, porque es lo más cómodo.


        Instala un driver de ratón para DOS

        El más cómodo hoy en día es CuteMouse, normalmente con el archivo:

        CTMOUSE.EXE

        Puedes meterlo en una ISO, en un disquete o copiarlo al disco duro de DOS.

        Por ejemplo, crea esta carpeta:

        C:
        CD \
        MD MOUSE

        Y copia dentro CTMOUSE.EXE, quedando así:

        C:\MOUSE\CTMOUSE.EXE

        Carga el driver manualmente

        Desde MS-DOS prueba:

        C:\MOUSE\CTMOUSE.EXE

        Cargar el ratón automáticamente al arrancar

        Edita AUTOEXEC.BAT:

        EDIT C:\AUTOEXEC.BAT

        Añade esta línea antes de ejecutar juegos:

        C:\MOUSE\CTMOUSE.EXE

        Ejemplo:

        @ECHO OFF
        PROMPT $p$g
        PATH C:\DOS;C:\MOUSE
        C:\MOUSE\CTMOUSE.EXE
        C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D
        KEYB SP,,C:\DOS\KEYBOARD.SYS

        Guarda, reinicia y prueba otra vez.

        Crear una imagen ISO con ImgBurn

        Una de las formas más cómodas de pasar archivos desde nuestro equipo moderno a una máquina emulada en 86Box es crear una imagen ISO. Esta imagen se comportará como si fuera un CD-ROM real dentro del ordenador emulado.

        Para hacerlo podemos utilizar ImgBurn, una herramienta clásica para crear y grabar imágenes de disco. Aunque su interfaz tiene un aspecto algo antiguo, sigue siendo muy útil para este tipo de tareas retro.

        La idea es sencilla: primero preparamos una carpeta en nuestro ordenador con todos los archivos que queremos llevar a MS-DOS o Windows 9x, y después convertimos esa carpeta en un archivo .iso.

        Por ejemplo, podemos crear una carpeta llamada:

        C:\CD_86BOX

        Dentro de esa carpeta podemos meter juegos, drivers, utilidades, instaladores o cualquier archivo que queramos usar dentro de la máquina virtual:

        C:\CD_86BOX\JUEGOS
        C:\CD_86BOX\DRIVERS
        C:\CD_86BOX\UTILS
        C:\CD_86BOX\README.TXT

        Una vez preparada la carpeta, abrimos ImgBurn y seleccionamos la opción:

        Create image file from files/folders

        Esta opción permite crear una imagen ISO a partir de una carpeta de nuestro disco duro.

        Después añadimos la carpeta que hemos preparado, elegimos dónde queremos guardar la imagen ISO resultante y pulsamos el botón para crearla. Por ejemplo, podemos guardar el archivo como:

        C:\ISOS\cd_86box.iso

        Cuando termine el proceso, ya tendremos un CD-ROM virtual listo para usar en 86Box.

        Instalación de Windows 3.11 desde una ISO de CD-ROM

        Una vez que el IBM PS/ValuePoint ya tiene MS-DOS instalado, el siguiente paso lógico es añadir un entorno gráfico clásico. Para este proyecto vamos a instalar Windows 3.11 desde una imagen ISO montada como CD-ROM en 86Box.

        Aunque Windows 3.11 se distribuía normalmente en disquetes, para trabajar de forma más cómoda en el emulador podemos preparar una ISO con los archivos de instalación. Esto facilita mucho el proceso, evita tener que cambiar disquetes constantemente y nos permite tener en un único CD virtual tanto Windows como drivers, utilidades y pequeños programas de la época.


        Requisitos previos

        Antes de empezar, el sistema debe tener:

        ElementoEstado necesario
        MS-DOSInstalado y arrancando desde C:
        CD-ROMDetectado como unidad D:
        Driver CD-ROMOAKCDROM.SYS cargado en CONFIG.SYS
        MSCDEXCargado en AUTOEXEC.BAT
        RatónRecomendable, aunque no imprescindible
        RAMMínimo 4 MB, recomendado 8 MB o 16 MB

        Para comprobar que el CD-ROM funciona, desde DOS podemos escribir:

        D:
        DIR

        Si aparece el contenido del CD, ya podemos continuar con la instalación.

        Durante la instalación de Windows para Trabajo en Grupo 3.11, Microsoft solicitaba un nombre de usuario, una organización y un número de producto. Este número venía normalmente en la tarjeta de registro, en la documentación original o en el material incluido con la licencia del programa.

        A diferencia de las versiones modernas de Windows, este número no funcionaba como una activación online. En aquella época no existía todavía el sistema de validación por Internet que asociamos a Windows XP, Windows 10 o Windows 11. El instalador simplemente pedía el dato como parte del proceso de registro e identificación del producto.

        Esto refleja muy bien cómo era el software comercial de principios de los años 90: el control de licencia dependía mucho más de la documentación física, los manuales, los certificados de autenticidad, las etiquetas y los disquetes o CD originales. El número de producto servía para identificar la copia instalada y facilitar el soporte técnico, pero el sistema no se conectaba a ningún servidor para comprobarlo.

        En nuestro caso, dentro del laboratorio retro con 86Box, esta pantalla resulta curiosa porque nos recuerda una época en la que instalar Windows era también un pequeño ritual: escribir el nombre, la empresa, el número del producto, elegir componentes, seleccionar el tipo de pantalla, configurar impresoras y terminar arrancando el clásico Administrador de programas.

        Una vez instalado ponemos en la terminal:

        win


        Instalar DOOM desde una imagen de CD

        Para instalar DOOM en nuestro IBM PS/ValuePoint emulado con 86Box, he optado por un método sencillo y bastante cómodo: crear una imagen ISO con los archivos del juego y montarla como si fuera un CD-ROM dentro de la máquina virtual.

        Una vez creada la ISO y configurado correctamente el lector de CD-ROM en MS-DOS, el sistema detecta la unidad como D:. Desde ahí podemos comprobar el contenido del disco con:

        D:
        DIR

        En este caso, la imagen contiene directamente los archivos del juego, así que no necesitamos un instalador complejo. Basta con crear una carpeta en el disco duro de la máquina y copiar allí el contenido del CD.

        Por ejemplo:

        C:
        CD \
        MD DOOM
        COPY D:\*.* C:\DOOM

        Si el juego está dentro de una carpeta del CD, por ejemplo D:\DOOM, usaríamos:

        C:
        CD \
        MD DOOM
        COPY D:\DOOM\*.* C:\DOOM

        Después entramos en la carpeta del juego:

        CD \DOOM
        DIR

        Y buscamos el ejecutable principal. Normalmente encontraremos archivos como:

        DOOM.EXE
        SETUP.EXE
        README.TXT

        Antes de jugar conviene ejecutar el programa de configuración:

        SETUP

        Desde ahí podemos ajustar el sonido, la música y los controles. En una máquina emulada es habitual tener que probar varias opciones de sonido hasta encontrar la que mejor funciona.

        Finalmente, para ejecutar el juego:

        DOOM

        Si el juego arranca pero no reconoce el ratón, no es un fallo de DOOM: MS-DOS necesita tener cargado previamente un controlador de ratón, como CTMOUSE.EXE o MOUSE.COM. Que el ratón funcione en Windows 3.11 no significa necesariamente que esté disponible también para los juegos de DOS.

        Este método de instalación es muy práctico porque nos permite preparar los archivos cómodamente desde nuestro ordenador actual, crear una ISO y usarla en 86Box como si fuera un CD real. Para un proyecto retro, además, mantiene bastante bien la sensación de estar trabajando con hardware y software de la época.

      4. Módulo 1. Introducción a la documentación técnica

        Módulo 1. Introducción a la documentación técnica

        En este primer módulo vamos a sentar las bases del curso. Antes de aprender a hacer README, manuales, esquemas o documentación profesional, es importante entender qué es realmente la documentación técnica, por qué es tan importante y por qué en tantos proyectos termina siendo un desastre o directamente no existe.

        La idea de esta unidad es que el alumno comprenda que documentar no es “rellenar papel”, sino una parte fundamental del trabajo técnico. Un proyecto mal documentado puede convertirse en un problema incluso aunque técnicamente esté bien hecho.

        En este módulo se trabajará:

        • qué es la documentación técnica
        • por qué suele fallar la documentación en proyectos reales
        • diferencias entre documentar para uno mismo, para un equipo y para un cliente
        • tipos de documentación en informática

        ¿Qué es la documentación técnica?

        La documentación técnica es el conjunto de textos, esquemas, instrucciones, referencias y evidencias que explican cómo funciona un sistema, cómo se instala, cómo se usa, cómo se mantiene o cómo se ha construido.

        Dicho de forma sencilla:
        la documentación técnica sirve para que una persona pueda entender, usar, mantener, revisar o continuar un trabajo técnico sin depender totalmente de quien lo creó.

        Ejemplos de documentación técnica

        En informática, documentación técnica puede ser por ejemplo:

        • un README de un proyecto en GitHub
        • un manual de instalación de un servidor
        • una guía de despliegue de una aplicación
        • un documento con la arquitectura de una red
        • un procedimiento para hacer copias de seguridad
        • una memoria técnica de un proyecto
        • un informe de auditoría o de incidencia
        • una wiki interna con procesos y configuraciones

        ¿Por qué es tan importante documentar?

        Porque en el mundo real los proyectos no viven solo el día que se crean.

        Un proyecto técnico normalmente pasa por varias fases:

        • se diseña
        • se implementa
        • se prueba
        • se entrega
        • se mantiene
        • se modifica
        • se corrige
        • se reutiliza o amplía

        Si no existe documentación, todo depende de la memoria de una persona.
        Y eso provoca errores, pérdida de tiempo, dependencia del autor original y muchos problemas cuando hay que revisar o retomar el trabajo.

        Una idea clave

        Un proyecto sin documentación puede funcionar hoy, pero convertirse en un problema mañana.


        ¿Qué suele pasar en los proyectos reales?

        En muchísimos proyectos la documentación falla por motivos muy parecidos.

        Problemas habituales

        • no se documenta desde el principio
        • se deja “para el final”
        • se escribe deprisa y sin estructura
        • se da por hecho que cosas importantes “ya se entienden”
        • se documenta pensando solo en quien lo ha hecho
        • la documentación se queda desactualizada
        • no se distingue entre tipos de documento
        • se mezcla información técnica, organizativa y personal sin orden
        • no se incluyen evidencias, validaciones ni contexto

        Resultado de todo esto

        Al final aparecen documentos que:

        • no sirven para instalar nada
        • no explican bien el proyecto
        • no ayudan a otra persona
        • no permiten reproducir el trabajo
        • quedan abandonados
        • generan confusión en lugar de ayudar

        Documentar no es escribir mucho

        Uno de los errores más frecuentes es pensar que “más texto” significa “mejor documentación”.

        No siempre es así.

        Una buena documentación no tiene por qué ser enorme.
        Tiene que ser:

        • clara
        • ordenada
        • útil
        • precisa
        • fácil de consultar
        • pensada para quien la va a leer

        Hay documentación breve que funciona muy bien, y documentación larguísima que no sirve para nada.


        ¿Para quién se documenta?

        Esta es una de las preguntas más importantes del módulo.

        No se documenta igual para todos los destinatarios.
        La forma de documentar cambia mucho según quién va a leer el documento.


        Documentar para uno mismo

        Cuando una persona documenta para sí misma, normalmente busca:

        • recordar pasos
        • guardar comandos
        • anotar configuraciones
        • dejar registro de errores y soluciones
        • construir una base de conocimiento personal

        Características habituales

        • más libertad en el formato
        • lenguaje más directo
        • menos contexto general
        • más valor práctico inmediato
        • organización pensada para el propio autor

        Ejemplo

        Una nota en Obsidian con comandos para configurar Apache y MySQL en Ubuntu.


        Documentar para un equipo

        Cuando se documenta para un equipo, la documentación debe ser más clara, más ordenada y más estandarizada.

        Aquí ya no basta con que “yo lo entienda”.
        Tiene que entenderlo otra persona que quizá no estuvo presente durante el proceso.

        Características habituales

        • lenguaje más claro y neutral
        • estructura estable
        • pasos reproducibles
        • mayor precisión
        • contexto suficiente
        • convenciones compartidas
        • mantenimiento continuo

        Ejemplo

        Una guía interna para desplegar una aplicación web en un servidor de pruebas.


        Documentar para un cliente o para una entrega formal

        Aquí la documentación debe tener además una presentación más cuidada y una explicación más completa del contexto, objetivos y resultados.

        Características habituales

        • tono más profesional
        • mejor presentación visual
        • organización muy clara
        • explicación de objetivos, alcance y resultados
        • vocabulario comprensible para perfiles no tan técnicos
        • formato más formal: Word, PDF, memoria, informe, etc.

        Ejemplo

        La memoria técnica de un proyecto final, con portada, índice, imágenes, fases, decisiones técnicas y conclusiones.


        Comparativa rápida

        Tipo de documentaciónDestinatarioObjetivo principalEstilo habitual
        PersonalUno mismoRecordar y reutilizarDirecto y práctico
        De equipoCompañeros o técnicosCompartir conocimiento y mantener procesosClaro, estructurado y reproducible
        Formal o de clienteProfesorado, cliente, responsables, tribunalExplicar, justificar y entregarProfesional, completo y bien presentado

        Tipos de documentación en informática

        En informática no existe un solo tipo de documentación.
        Hay varias categorías, y cada una cumple una función diferente.

        Entender esto es muy importante porque muchos errores vienen de mezclarlo todo en un solo documento.


        1. Documentación de producto

        Es la documentación que explica un producto, una aplicación, un sistema o una herramienta concreta.

        Suele incluir

        • qué es
        • para qué sirve
        • cómo se instala
        • cómo se configura
        • cómo se usa
        • qué requisitos tiene
        • qué estructura interna presenta

        Ejemplos

        • README de una aplicación
        • manual de usuario técnico
        • documentación de API
        • guía de instalación de software

        2. Documentación de proceso

        Explica cómo se realiza una tarea o un conjunto de tareas.

        No se centra tanto en “qué es el producto”, sino en qué pasos hay que seguir para hacer algo correctamente.

        Suele incluir

        • objetivo del proceso
        • requisitos previos
        • secuencia de pasos
        • validación
        • problemas frecuentes
        • resultado esperado

        Ejemplos

        • procedimiento de despliegue
        • guía de copia de seguridad
        • proceso de alta de usuarios
        • checklist de hardening
        • guía de restauración de servicios

        3. Documentación operativa

        Es la documentación que sirve para operar, administrar o mantener sistemas en funcionamiento.

        Está muy relacionada con ASIR, sistemas, administración, redes y explotación técnica.

        Suele incluir

        • configuraciones
        • servicios
        • puertos
        • rutas
        • comandos
        • validaciones
        • acciones de mantenimiento
        • actuación ante fallos

        Ejemplos

        • runbook de administración
        • guía de reinicio de servicios
        • procedimientos de monitorización
        • documentación de una infraestructura de red
        • inventario técnico de máquinas o servicios

        4. Documentación de soporte

        Es la documentación pensada para resolver dudas, incidencias o problemas recurrentes.

        Suele incluir

        • preguntas frecuentes
        • errores comunes
        • pasos de comprobación
        • diagnósticos básicos
        • soluciones conocidas

        Ejemplos

        • FAQ técnica
        • base de conocimiento
        • guía de resolución de incidencias
        • documentación de errores frecuentes

        5. Documentación académica y de entrega

        Es muy habitual en entornos educativos, proyectos fin de ciclo, memorias, prácticas guiadas y entregas técnicas.

        Aquí no solo importa el funcionamiento, sino también explicar el proceso, justificar decisiones y demostrar el trabajo realizado.

        Suele incluir

        • introducción
        • objetivos
        • análisis
        • requisitos
        • diseño
        • implementación
        • capturas
        • pruebas
        • conclusiones
        • bibliografía o referencias

        Ejemplos

        • memoria de TFG o TFM
        • entrega de una práctica técnica
        • informe de laboratorio
        • documentación de un proyecto de clase

        6. Documentación viva vs. documentación abandonada

        Este punto es especialmente importante.

        Documentación viva

        Es la que se mantiene actualizada y sigue siendo útil con el paso del tiempo.

        Características

        • se revisa
        • se corrige
        • se adapta a cambios
        • refleja el estado real del proyecto
        • acompaña al trabajo técnico

        Documentación abandonada

        Es la que se escribió una vez y nunca más se revisó.

        Problemas típicos

        • comandos que ya no sirven
        • capturas antiguas
        • rutas que han cambiado
        • versiones desactualizadas
        • información incompleta o engañosa

        Idea importante

        Una documentación antigua puede ser peor que no tener documentación, porque da una falsa sensación de confianza.


        Ejemplo sencillo para entenderlo

        Imagina una práctica donde un alumno monta un servidor web con Apache, PHP y MySQL.

        Si documenta bien:

        • explica requisitos
        • indica comandos
        • organiza pasos
        • muestra validaciones
        • añade errores encontrados
        • incluye estructura del proyecto
        • deja claro cómo reproducirlo

        Si documenta mal:

        • pone cuatro comandos sueltos
        • no indica orden
        • no explica qué instaló realmente
        • no muestra resultado
        • no aclara versiones ni rutas
        • no se entiende qué hizo ni cómo repetirlo

        Técnicamente puede haber hecho lo mismo, pero el valor del trabajo cambia muchísimo.


        Errores muy frecuentes al empezar a documentar

        Estos errores conviene enseñarlos desde el principio:

        • escribir pensando “ya me acordaré”
        • no poner títulos claros
        • mezclar teoría y práctica sin orden
        • usar frases ambiguas
        • copiar comandos sin explicar para qué sirven
        • no validar resultados
        • no anotar problemas reales
        • no diferenciar entre borrador y versión final
        • documentar solo el resultado y no el proceso




        Ejemplos

        CasoTipo de documentaciónDestinatarioObservación
        README de instalaciónDocumentación de productoUsuario técnico o desarrolladorExplica qué es y cómo usarlo
        Documento en Word con memoriaDocumentación académica y de entregaProfesorado, cliente o tribunalPresentación formal
        Nota de Obsidian con comandosDocumentación personal u operativaUno mismoUso interno y práctico
        Guía de despliegue en ApacheDocumentación de proceso u operativaEquipo técnicoProcedimiento reproducible
        Lista de errores frecuentesDocumentación de soporteUsuarios o técnicosAyuda a resolver incidencias
        Documento obsoletoDocumentación abandonadaPuede confundir a cualquieraNo refleja la realidad actual

        Ideas clave para recordar

        Documentar no es decorar un proyecto: es hacerlo comprensible y mantenible.

        Una buena documentación ayuda a repetir, mantener, explicar y mejorar un trabajo técnico.

        No toda la documentación sirve para lo mismo: hay que elegir bien el tipo de documento.

        La documentación útil está pensada para quien la va a leer.

        Una documentación sin mantenimiento termina perdiendo valor.


        Caso de uso: despliegue de una aplicación web interna para gestión de incidencias

        Una pequeña empresa llamada NetSecure Solutions necesita una aplicación web interna para que el equipo técnico pueda registrar incidencias informáticas, asignarlas a distintos técnicos y hacer seguimiento de su resolución.

        Un desarrollador del equipo ha creado una primera versión de la aplicación usando:

        • PHP
        • MySQL
        • Apache
        • JavaScript
        • HTML y CSS

        La aplicación funciona, pero ahora surge un problema habitual en muchos proyectos técnicos:

        • el sistema debe instalarse también en otro servidor
        • otros técnicos tienen que poder mantenerlo
        • un responsable debe entender qué incluye el proyecto
        • si aparece un error, alguien debe saber cómo revisarlo
        • si el desarrollador original no está, el trabajo debe poder continuar

        Para evitar depender únicamente de la memoria del autor, el equipo decide crear una documentación técnica completa del proyecto.

        ¿Qué documentación necesitarían?

        En este caso podrían necesitar, por ejemplo:

        • un README principal para explicar el proyecto
        • una guía de instalación para desplegarlo en otro equipo
        • una guía de configuración de la base de datos
        • una documentación de estructura del proyecto
        • una guía operativa para revisar logs y reiniciar servicios
        • una base de incidencias frecuentes
        • una memoria técnica para presentar el proyecto a dirección o a un cliente

        ¿Por qué este caso de uso es bueno para el módulo?

        Porque permite ver claramente que:

        • no toda la documentación sirve para lo mismo
        • un único documento no siempre es suficiente
        • el destinatario cambia según el documento
        • un proyecto técnico necesita más de un tipo de documentación

        Ejemplo de índice

        A continuación tienes un índice de ejemplo para la documentación de este proyecto ficticio. Te puede servir para enseñar a los alumnos cómo se organiza un documento técnico amplio.

        Índice de ejemplo: Documentación técnica del proyecto “NetSecure Tickets”

        1. Introducción

        1.1. Descripción general del proyecto
        1.2. Objetivo de la aplicación
        1.3. Alcance del sistema
        1.4. Público al que va dirigida esta documentación

        2. Visión general del proyecto

        2.1. Problema que resuelve
        2.2. Funcionalidades principales
        2.3. Tecnologías utilizadas
        2.4. Estructura general de funcionamiento

        3. Requisitos previos

        3.1. Requisitos de hardware
        3.2. Requisitos de software
        3.3. Versiones recomendadas
        3.4. Dependencias necesarias

        4. Instalación del entorno

        4.1. Instalación de Apache
        4.2. Instalación de PHP
        4.3. Instalación de MySQL
        4.4. Configuración inicial del servidor
        4.5. Verificación del entorno

        5. Despliegue de la aplicación

        5.1. Copia de archivos del proyecto
        5.2. Estructura de carpetas
        5.3. Configuración de conexión a base de datos
        5.4. Importación de la base de datos
        5.5. Prueba inicial de funcionamiento

        6. Uso básico de la aplicación

        6.1. Pantalla principal
        6.2. Registro de incidencias
        6.3. Consulta de incidencias
        6.4. Asignación a técnicos
        6.5. Cierre de incidencias

        7. Estructura técnica del proyecto

        7.1. Organización de archivos
        7.2. Archivos principales
        7.3. Relación entre frontend y backend
        7.4. Base de datos y tablas utilizadas

        8. Procedimientos operativos

        8.1. Reinicio de servicios
        8.2. Revisión de logs
        8.3. Copia de seguridad de la base de datos
        8.4. Restauración básica
        8.5. Comprobaciones de estado

        9. Incidencias frecuentes

        9.1. Error de conexión a MySQL
        9.2. Error 403 o 404 en Apache
        9.3. Problemas con permisos de archivos
        9.4. Fallos al cargar estilos o scripts
        9.5. Errores comunes y solución

        10. Mejoras futuras

        10.1. Autenticación de usuarios
        10.2. Panel de administración
        10.3. Exportación de incidencias
        10.4. Sistema de avisos por correo

        11. Conclusiones

        11.1. Resultado obtenido
        11.2. Valor del sistema
        11.3. Posibles ampliaciones

        12. Anexos

        12.1. Capturas de pantalla
        12.2. Comandos utilizados
        12.3. Script SQL inicial
        12.4. Referencias técnicas


        Versión más corta de índice para un README

        Si quieres enseñar también la diferencia entre un documento amplio y un README más simple, podrías poner este otro ejemplo:

        Índice de ejemplo de README

        1. Nombre del proyecto
        2. Descripción
        3. Objetivo
        4. Tecnologías utilizadas
        5. Requisitos previos
        6. Instalación
        7. Configuración
        8. Ejecución
        9. Estructura del proyecto
        10. Problemas frecuentes
        11. Mejoras futuras
        12. Autor

      5. Módulo 2. Principios de una buena documentación técnica

        Módulo 2. Principios de una buena documentación técnica

        En el módulo anterior vimos qué es la documentación técnica, por qué es importante y qué tipos de documentación existen en informática.
        Ahora toca dar un paso más: entender qué hace que una documentación sea realmente buena.

        Porque no basta con documentar.
        También hay que documentar bien.

        En este módulo el alumno aprenderá cuáles son los principios que convierten un documento técnico en algo útil, claro y profesional. También verá errores muy frecuentes al redactar documentación y aprenderá a detectarlos y corregirlos.

        En esta unidad se trabajará:

        • claridad
        • precisión
        • estructura
        • consistencia
        • legibilidad
        • errores comunes al redactar documentos técnicos

        ¿Qué significa documentar bien?

        Documentar bien significa crear un documento que otra persona pueda leer y usar sin perder tiempo, sin interpretar cosas ambiguas y sin tener que preguntarle constantemente al autor.

        Una buena documentación técnica debe ayudar a responder preguntas como estas:

        • ¿qué es esto?
        • ¿para qué sirve?
        • ¿cómo se instala?
        • ¿cómo se usa?
        • ¿qué pasos hay que seguir?
        • ¿qué requisitos tiene?
        • ¿cómo sé si funciona?
        • ¿qué hago si falla?

        Si el documento no ayuda a responder este tipo de preguntas, entonces probablemente está incompleto o mal planteado.


        Idea clave del módulo

        Una documentación técnica no se valora por lo mucho que ocupa, sino por lo útil que resulta.


        1. Claridad

        La claridad es uno de los pilares más importantes de cualquier documentación técnica.

        Un documento claro permite que el lector entienda rápido lo que se le está explicando.
        No obliga a releer varias veces una frase ni a deducir lo que el autor quería decir.

        Una documentación clara:

        • usa frases directas
        • evita rodeos innecesarios
        • explica cada paso de forma comprensible
        • separa bien las ideas
        • no mezcla demasiadas cosas en el mismo apartado

        Ejemplo poco claro

        Aquí habría que configurar el servidor para que funcione correctamente según lo que se necesite.

        Ejemplo más claro

        Edita el archivo de configuración de Apache y cambia el puerto de escucha a 8080. Después reinicia el servicio con systemctl restart apache2.

        En el segundo caso, el lector sabe exactamente qué hacer.


        2. Precisión

        La claridad no basta si el documento no es preciso.

        La precisión consiste en explicar las cosas de forma concreta, exacta y verificable.

        Una documentación precisa:

        • indica rutas reales
        • usa nombres correctos
        • menciona versiones cuando importa
        • diferencia comandos parecidos
        • evita expresiones vagas como “lo normal”, “más o menos”, “si hace falta”, “como siempre”

        Ejemplo impreciso

        Instala la base de datos y configura el usuario.

        Ejemplo preciso

        Instala MySQL Server, crea la base de datos inventario, y después crea el usuario appuser con permisos sobre esa base de datos.

        La segunda versión reduce dudas y mejora la reproducibilidad.


        3. Estructura

        Muchas veces un documento falla no porque su contenido sea malo, sino porque está mal organizado.

        Un texto técnico necesita una estructura lógica.
        El lector debe saber dónde empieza una idea, dónde están los pasos, dónde están los requisitos y dónde están los problemas frecuentes.

        Una buena estructura suele separar:

        • introducción o contexto
        • objetivo
        • requisitos previos
        • pasos a realizar
        • validación
        • errores frecuentes
        • conclusiones o siguientes pasos

        Problema muy común

        Hay documentación donde se mezclan:

        • teoría
        • comandos
        • capturas
        • opiniones
        • errores
        • resultados

        …todo ello sin ningún orden.

        Eso hace que el lector tenga que “buscar” la información en lugar de encontrarla de forma natural.


        Ejemplo de estructura básica útil

        1. Objetivo

        Qué se va a hacer.

        2. Requisitos previos

        Qué hace falta antes de empezar.

        3. Procedimiento

        Pasos ordenados.

        4. Validación

        Cómo comprobar que ha salido bien.

        5. Problemas frecuentes

        Qué errores pueden aparecer.

        6. Resultado final

        Qué se ha conseguido.


        4. Consistencia

        La consistencia significa mantener el mismo criterio a lo largo de todo el documento.

        Por ejemplo:

        • usar siempre los mismos nombres para las mismas cosas
        • no cambiar de estilo en cada apartado
        • seguir la misma lógica en títulos y subtítulos
        • mantener el mismo formato para comandos, rutas, tablas y notas

        Ejemplo de falta de consistencia

        En una parte del documento escribes:

        • Base de datos
        • Usuario administrador
        • Carpeta del proyecto

        Y más adelante escribes:

        • BD
        • admin
        • directorio principal

        Aunque no parezca grave, este tipo de cambios genera confusión.

        También afecta al formato

        Por ejemplo, no conviene que en una parte los comandos estén así:

        sudo apt update

        y más adelante aparezcan mezclados dentro del texto sin destacar, o que unas rutas lleven formato y otras no.

        La consistencia da sensación de orden y profesionalidad.


        5. Legibilidad

        La legibilidad tiene que ver con lo fácil que resulta leer y recorrer el documento.

        No solo importa lo que se dice, sino cómo se presenta.

        Mejora la legibilidad:

        • usar títulos claros
        • crear apartados cortos
        • usar listas cuando conviene
        • separar bloques de código
        • dejar espacio entre secciones
        • usar tablas si ayudan a resumir
        • destacar notas importantes
        • no escribir párrafos gigantescos

        Ejemplo de mala legibilidad

        Un texto largo, sin subtítulos, con comandos mezclados dentro de frases muy extensas.

        Ejemplo de buena legibilidad

        Un documento con:

        • apartados definidos
        • comandos en bloques
        • pasos numerados
        • advertencias visibles
        • ejemplos separados del texto principal

        La legibilidad es especialmente importante en documentación técnica porque muchas veces no se lee de principio a fin: se consulta por partes.


        6. Orientación al lector

        Una documentación técnica no debe escribirse pensando solo en quien la redacta.
        Debe escribirse pensando en quien la va a usar.

        Eso significa que el documento debe adaptarse al perfil del lector.

        No es lo mismo escribir para:

        • uno mismo
        • un compañero técnico
        • un profesor
        • un cliente
        • un usuario final

        Ejemplo

        Si documentas una práctica para alumnos principiantes, probablemente debas incluir:

        • más contexto
        • pasos más detallados
        • explicaciones de comandos
        • ejemplos visuales

        Si documentas para un equipo técnico experto, quizá puedas ser más directo y conciso.


        7. Reproducibilidad

        Una de las mejores formas de medir la calidad de una documentación técnica es esta:

        ¿Otra persona podría repetir el proceso con ese documento?

        Si la respuesta es no, entonces la documentación no está cumpliendo bien su función.

        Para que un documento sea reproducible debe incluir:

        • requisitos previos
        • pasos en orden
        • comandos completos
        • rutas correctas
        • parámetros importantes
        • validación de resultado
        • contexto mínimo

        Ejemplo

        No basta con poner:

        Configura Apache para el proyecto.

        Eso no es reproducible.

        Es mejor algo como:

        1. Copia el proyecto a /var/www/html/app.
        2. Edita el archivo de virtual host.
        3. Define DocumentRoot /var/www/html/app.
        4. Activa el sitio.
        5. Reinicia Apache.
        6. Comprueba el acceso desde el navegador.

        8. Mantenibilidad

        Una buena documentación no debe servir solo hoy.
        También debe poder mantenerse con cierta facilidad.

        Una documentación mantenible:

        • está bien organizada
        • tiene secciones reutilizables
        • se puede actualizar sin rehacerla entera
        • separa lo estable de lo que cambia mucho
        • evita repeticiones innecesarias

        Ejemplo

        Si una versión del software cambia con frecuencia, conviene que la documentación tenga una sección concreta para versiones o requisitos, en lugar de repartir esa información por todo el documento.


        Errores comunes al redactar documentación técnica

        Ahora vamos a ver algunos de los errores más frecuentes. Esta parte suele ayudar mucho a los alumnos porque les permite reconocer fallos típicos que ellos mismos cometen al empezar.


        Error 1. Dar cosas por supuestas

        El autor sabe lo que ha hecho y cree que el lector también lo entenderá.

        Ejemplo

        Configuramos el servicio como siempre y continuamos con la instalación.

        Problema:
        ¿Como siempre según quién?
        Eso solo lo entiende quien lo escribió.


        Error 2. Escribir pasos incompletos

        A veces se omiten pasos porque parecen obvios.

        Ejemplo

        Importa la base de datos y ejecuta la aplicación.

        Pero quizá falta indicar:

        • qué archivo SQL usar
        • con qué usuario
        • sobre qué base de datos
        • en qué orden hacerlo

        Error 3. No validar resultados

        Muchos alumnos ponen comandos, pero no indican cómo comprobar que funcionó.

        Ejemplo

        Instala Apache.

        Bien, pero falta decir:

        • cómo comprobar que está activo
        • qué comando usar
        • qué respuesta esperar
        • qué debería verse en navegador

        Error 4. Mezclar demasiadas cosas en el mismo apartado

        Por ejemplo, juntar en una misma sección:

        • teoría
        • comandos
        • explicación de errores
        • decisiones de diseño
        • conclusiones

        Esto vuelve la documentación caótica.


        Error 5. Usar frases ambiguas

        Ejemplos típicos

        • “configura lo necesario”
        • “haz los cambios correspondientes”
        • “instala lo que falte”
        • “corrige los errores si aparecen”

        Este tipo de redacción parece técnica, pero en realidad aporta muy poca información útil.


        Error 6. No adaptar el nivel de detalle

        A veces la documentación es tan breve que no sirve.
        Otras veces tiene tanto detalle irrelevante que entorpece la lectura.

        Hay que encontrar el nivel adecuado según el público y el objetivo.


        Error 7. No diferenciar entre borrador y documentación final

        Una lista rápida de notas personales no es lo mismo que una guía lista para entregar o compartir.

        Es importante enseñar al alumno que documentar también implica revisar, ordenar y pulir.


        Cómo mejorar una mala documentación

        Una buena forma de enseñar este módulo es mostrar que mejorar documentación no siempre significa reescribir todo desde cero.

        Muchas veces basta con aplicar una revisión guiada.

        Preguntas de revisión útiles

        Antes de dar un documento por bueno, conviene revisar:

        • ¿se entiende el objetivo?
        • ¿queda claro para quién está escrito?
        • ¿los pasos están ordenados?
        • ¿faltan requisitos previos?
        • ¿hay validación?
        • ¿hay frases ambiguas?
        • ¿se usan siempre los mismos términos?
        • ¿se puede localizar rápido cada parte?
        • ¿otra persona podría repetir el proceso?

        Ejemplo práctico: de documentación deficiente a documentación útil

        Versión deficiente

        Instalamos el servidor, cambiamos unas cosas de configuración y luego metemos la base de datos. Después ya se puede probar el proyecto. Si da error habrá que revisar permisos o la conexión.

        Versión mejorada

        Instalación del entorno

        1. Instala Apache con el comando:
        sudo apt install apache2 -y
        1. Instala MySQL Server:
        sudo apt install mysql-server -y
        1. Crea la base de datos proyecto_web:
        CREATE DATABASE proyecto_web;
        1. Importa el archivo proyecto_web.sql en esa base de datos.
        2. Copia los archivos del proyecto a:
        /var/www/html/proyecto_web
        1. Comprueba en el navegador que la aplicación responde correctamente.

        Validación

        • Verifica que Apache esté activo con:
        systemctl status apache2
        • Comprueba que MySQL esté funcionando:
        systemctl status mysql

        Aquí ya vemos claridad, estructura, precisión y validación.


        Qué debe aprender el alumno en este módulo

        Al terminar esta unidad, el alumno debe ser capaz de:

        • identificar si una documentación es clara o confusa
        • detectar frases ambiguas o imprecisas
        • organizar mejor un documento técnico
        • aplicar criterios de consistencia y legibilidad
        • redactar pasos reproducibles
        • revisar una documentación para mejorarla antes de entregarla

        Resultado práctico del módulo

        El alumno analiza una documentación técnica sencilla, detecta sus fallos y la mejora aplicando principios de claridad, precisión, estructura, consistencia y legibilidad.


        Actividad propuesta para el módulo

        Actividad: detectar y corregir errores de documentación

        Lee este fragmento de documentación:

        Se instala el servidor web y luego se configura todo para que funcione con la aplicación. Después se mete la base de datos y se comprueba si va bien. Si falla, revisar lo necesario.

        Tareas del alumno

        1. Indica qué problemas tiene este texto.
        2. Señala al menos 5 aspectos que deberían mejorarse.
        3. Reescribe el fragmento para convertirlo en una documentación técnica más útil.

        Solución orientativa

        Problemas detectados

        • no indica qué servidor web se instala
        • no explica qué significa “configurar todo”
        • no especifica cómo se importa la base de datos
        • no incluye rutas ni comandos
        • no explica cómo comprobar que funciona
        • no concreta qué hacer si falla

        Reescritura mejorada

        Instalación y configuración básica

        1. Instala Apache:
        sudo apt install apache2 -y
        1. Copia la aplicación a la carpeta:
        /var/www/html/app_incidencias
        1. Crea la base de datos app_incidencias en MySQL.
        2. Importa el archivo app_incidencias.sql.
        3. Edita el archivo de configuración de la aplicación para introducir:
        • nombre de la base de datos
        • usuario
        • contraseña
        • host
        1. Abre el navegador y accede a la URL del proyecto para comprobar que carga correctamente.

        Validación

        • comprueba el estado de Apache
        • verifica la conexión con MySQL
        • revisa permisos de archivos si la aplicación no carga

        Caso de uso inventado para este módulo

        Imagina que un alumno ha montado una pequeña aplicación de gestión de tareas en PHP y MySQL.
        Quiere entregar la práctica, pero su documentación consiste solo en:

        • una lista de comandos sueltos
        • una captura de la web funcionando
        • una frase que dice “la instalación es sencilla”
        • una mención rápida a la base de datos

        Aunque la aplicación funcione, esa documentación no sería suficiente para:

        • repetir el despliegue
        • corregir errores
        • mantener el proyecto
        • evaluarlo correctamente
        • entregarlo de forma profesional

        El problema no es solo el contenido técnico, sino cómo está explicado.


        Ejemplo de índice para un documento bien estructurado

        Índice de ejemplo

        1. Introducción
        2. Objetivo del documento
        3. Requisitos previos
        4. Instalación del entorno
        5. Configuración de la base de datos
        6. Despliegue de la aplicación
        7. Validación del funcionamiento
        8. Problemas frecuentes
        9. Conclusión

        Este índice ya muestra una secuencia lógica y fácil de seguir.


        Ideas clave para recordar

        Una buena documentación debe ser clara, precisa y útil.

        Si un paso no se puede repetir, la documentación está incompleta.

        Escribir mucho no garantiza documentar bien.

        Una estructura ordenada facilita muchísimo el trabajo técnico.

        La revisión final forma parte de la documentación.

      6. Laboratorio móvil de ciberseguridad 1: construyendo una maleta técnica para redes, sistemas y proyectos ASIR

        Laboratorio móvil de ciberseguridad 1: construyendo una maleta técnica para redes, sistemas y proyectos ASIR

        🎧 Resumen en audio del tema
        Escucha este audio para repasar las ideas y los objetivos principales de este proyecto antes de continuar o al finalizar la lectura.

        En muchas ocasiones, cuando trabajamos redes, sistemas, servidores, Raspberry Pi, sensores, monitorización o ciberseguridad, necesitamos montar pequeños laboratorios de prueba. A veces basta con una máquina virtual, otras veces usamos varias Raspberry, un switch, un router, discos duros, sensores, placas Arduino o algún equipo adicional.

        El problema es que estos montajes suelen acabar ocupando demasiado espacio sobre la mesa: cables por todas partes, transformadores, regletas, adaptadores, tarjetas microSD, discos externos, pantallas, teclados, routers, switches y placas sueltas.

        Por eso he decidido empezar un proyecto personal que iré documentando paso a paso: construir un laboratorio móvil dentro de una maleta, pensado para poder transportarlo, conectarlo rápidamente y usarlo como herramienta de trabajo en diferentes proyectos de ASIR, redes, sistemas y ciberseguridad.

        No se trata de una práctica para que la realicen directamente los alumnos, al menos no en esta primera fase. La idea es construir una herramienta propia que después pueda utilizar en clase, en demostraciones, en laboratorios guiados y en proyectos más avanzados.


        ¿Qué quiero construir?

        La idea inicial es montar una maleta rígida en cuyo interior irán fijados diferentes dispositivos de red y computación. Algunos de los elementos que estoy valorando incluir son:

        • un router o punto de acceso;
        • un switch de red;
        • una o varias Raspberry Pi;
        • una pantalla integrada;
        • discos SSD o discos duros externos;
        • alimentación centralizada;
        • ventilación;
        • conectores accesibles desde el exterior;
        • cableado interno ordenado;
        • posiblemente sensores, Arduino u otros módulos según evolucione el proyecto.

        La intención es que todo quede montado de forma fija, ordenada y segura, evitando tener que sacar y conectar cada elemento cada vez que quiera usar el laboratorio.

        La maleta funcionaría como una pequeña infraestructura portátil:

        Maleta abierta

        ├── Router / punto de acceso
        ├── Switch
        ├── Raspberry Pi
        ├── Almacenamiento
        ├── Pantalla
        ├── Alimentación interna
        └── Conexiones de red y periféricos

        ¿Para qué puede servir este laboratorio móvil?

        Este proyecto puede tener muchas aplicaciones dentro de la enseñanza de informática, especialmente en ciclos como ASIR y en módulos relacionados con redes, sistemas y ciberseguridad.

        Algunas ideas de uso son:

        • montar una pequeña red aislada para pruebas;
        • crear un entorno de ciberseguridad controlado;
        • simular una red de empresa;
        • desplegar servicios en Raspberry Pi;
        • practicar escaneos de red con herramientas como Nmap;
        • montar laboratorios con IDS, SIEM o monitorización;
        • hacer pruebas con sensores y recogida de datos;
        • crear un pequeño servidor portátil;
        • trabajar con copias de seguridad y almacenamiento;
        • enseñar conceptos de segmentación, servicios, puertos y tráfico de red;
        • documentar instalaciones reales paso a paso.

        No quiero que sea simplemente una “caja con aparatos”. La idea es que sea una plataforma didáctica reutilizable.


        Objetivos del proyecto

        El objetivo principal es construir un laboratorio portátil, funcional y documentado, que pueda utilizarse en diferentes contextos educativos y técnicos.

        Objetivos técnicos

        • Diseñar una maleta con dispositivos montados de forma fija.
        • Centralizar la alimentación para evitar múltiples transformadores.
        • Mantener separada la parte de 230 V AC de la parte de baja tensión DC.
        • Usar fusibles y protecciones para cada línea de alimentación.
        • Integrar router, switch, Raspberry Pi y almacenamiento.
        • Preparar ventilación para evitar problemas de temperatura.
        • Ordenar el cableado interno de forma clara y mantenible.
        • Dejar el montaje preparado para futuras ampliaciones.

        Objetivos didácticos

        • Mostrar a los alumnos cómo se planifica un proyecto técnico real.
        • Documentar decisiones, errores y mejoras.
        • Enseñar buenas prácticas de montaje, seguridad y organización.
        • Usar el laboratorio como base para prácticas de redes, sistemas y ciberseguridad.
        • Crear material reutilizable para futuras clases.
        • Mostrar que la informática no es solo software: también hay infraestructura, electricidad, hardware, montaje y mantenimiento.

        Por qué hacerlo dentro de una maleta

        Una maleta rígida permite crear un entorno compacto, transportable y relativamente protegido.

        Las ventajas principales son:

        VentajaExplicación
        PortabilidadSe puede llevar de un aula a otra o guardar fácilmente
        OrdenLos dispositivos quedan fijados y cableados
        RapidezSe abre, se conecta y se empieza a trabajar
        ProtecciónLos equipos quedan más protegidos que si estuvieran sueltos
        ReutilizaciónSirve para muchos proyectos diferentes
        PresentaciónVisualmente es más atractivo para explicar conceptos

        También tiene inconvenientes que hay que tener en cuenta:

        RiesgoMedida prevista
        Calor internoAñadir ventiladores y rejillas
        Exceso de cableadoUsar distribución ordenada y etiquetas
        Seguridad eléctricaSeparar 230 V y baja tensión
        MantenimientoMontar los equipos de forma accesible
        Ampliaciones futurasDejar espacio libre y conectores preparados

        Primera fase: definir la arquitectura

        Antes de cortar, atornillar o comprar componentes sin control, la primera fase será definir una arquitectura básica.

        La idea inicial podría ser algo así:

        Entrada 230 V AC

        ├── Enchufe interno para portátil o cargador auxiliar

        └── Fuente 230 V AC → 12 V DC

        ├── Router 12 V
        ├── Switch 12 V
        ├── Ventiladores 12 V
        └── Conversor 12 V → 5 V
        └── Raspberry Pi

        La parte importante aquí es que no todos los dispositivos funcionan al mismo voltaje.

        Por ejemplo:

        • el router puede necesitar 12 V;
        • el switch puede necesitar 5 V, 9 V o 12 V;
        • la Raspberry necesita 5 V;
        • los ventiladores pueden ir a 5 V o 12 V;
        • un portátil normalmente necesita su propio cargador a 230 V.

        Por tanto, una de las primeras tareas será identificar el consumo real de cada equipo.


        Alimentación: una de las partes más importantes

        Uno de los puntos más delicados del proyecto es la alimentación eléctrica.

        La solución más simple sería meter una regleta dentro de la maleta y conectar todos los transformadores originales, pero no es la opción más limpia ni la más eficiente en espacio.

        La solución que estoy valorando es usar una fuente central de 12 V y, desde ahí, repartir la alimentación mediante una caja de fusibles y conversores DC-DC.

        Un posible esquema sería:

        Fuente 12 V

        ├── Fusible 2 A → Router
        ├── Fusible 2 A → Switch
        ├── Fusible 3 A → Conversor 12 V a 5 V → Raspberry
        ├── Fusible 1 A → Ventiladores
        └── Fusible 1 A → Pantalla o accesorios

        Esto permite tener una instalación más ordenada, pero también obliga a hacerlo con cuidado.

        No se trata solo de que “funcione”. Tiene que ser seguro, mantenible y comprensible.


        Seguridad antes que estética

        Aunque el objetivo es que la maleta quede bien presentada, la prioridad será siempre la seguridad.

        Algunas normas que quiero seguir desde el principio:

        • no dejar conexiones de 230 V expuestas;
        • usar entrada de corriente con interruptor y fusible;
        • separar físicamente la zona de alta tensión y la zona de baja tensión;
        • proteger cada línea de 12 V con su fusible;
        • usar cable de sección adecuada;
        • evitar cables finos tipo Arduino para alimentar equipos;
        • comprobar polaridad y voltaje con multímetro antes de conectar nada;
        • añadir ventilación;
        • etiquetar cables y conexiones;
        • documentar cada cambio.

        Esto también forma parte del aprendizaje. Muchas veces en clase enseñamos servicios, comandos, configuraciones y herramientas, pero no siempre se ve la parte física de montar una pequeña infraestructura de forma ordenada.


        Posibles usos en ciberseguridad

        Uno de los motivos principales para construir esta maleta es poder usarla como base para laboratorios de ciberseguridad.

        Algunas posibilidades futuras:

        1. Laboratorio de escaneo y reconocimiento

        Usar la red interna de la maleta para practicar:

        • descubrimiento de hosts;
        • escaneo de puertos;
        • identificación de servicios;
        • pruebas con Nmap;
        • análisis de tráfico.

        2. Mini SOC educativo

        Integrar herramientas como:

        • Wazuh;
        • Suricata;
        • Grafana;
        • Prometheus;
        • logs centralizados;
        • alertas básicas.

        3. Red aislada de pruebas

        Crear un entorno donde se puedan levantar máquinas vulnerables o servicios de prueba sin afectar a la red real del aula.

        4. Servidor portátil

        Una Raspberry con almacenamiento podría actuar como:

        • servidor web;
        • servidor de ficheros;
        • servidor de logs;
        • panel de control;
        • repositorio local de documentación o scripts.

        5. Simulación de red empresarial

        Con router, switch y varios nodos se puede representar una pequeña red con:

        • clientes;
        • servidores;
        • segmentos;
        • servicios internos;
        • reglas de firewall;
        • monitorización.

        Documentar el proceso: una parte esencial del proyecto

        Este proyecto no solo consistirá en montar la maleta. También quiero documentar cada fase.

        La documentación incluirá:

        • materiales utilizados;
        • decisiones de diseño;
        • esquemas de conexión;
        • pruebas realizadas;
        • problemas encontrados;
        • soluciones aplicadas;
        • fotografías del montaje;
        • configuraciones de red;
        • scripts utilizados;
        • posibles mejoras;
        • conclusiones de cada fase.

        La idea es que cualquier persona que siga el proyecto pueda entender no solo el resultado final, sino también el razonamiento detrás de cada decisión.

        Porque en proyectos reales rara vez todo sale perfecto a la primera. Hay que medir, probar, corregir, reorganizar y volver a probar.


        Fases previstas del proyecto

        Aunque el diseño todavía está abierto, una posible planificación inicial sería la siguiente:

        FaseDescripción
        Fase 1Definir objetivos y componentes iniciales
        Fase 2Elegir la maleta y diseñar la distribución interna
        Fase 3Planificar la alimentación eléctrica
        Fase 4Montar fuente, fusibles y distribución de 12 V
        Fase 5Integrar router, switch y Raspberry Pi
        Fase 6Añadir pantalla y almacenamiento
        Fase 7Configurar red interna y servicios básicos
        Fase 8Preparar primeros laboratorios de prueba
        Fase 9Documentar errores, mejoras y ampliaciones
        Fase 10Usar la maleta en proyectos reales de clase

        Esta planificación podrá cambiar. De hecho, seguramente cambiará. Y eso también será parte del valor del proyecto.


        Qué componentes estoy valorando

        Por ahora, la lista de componentes posibles incluye:

        ComponenteFunción
        Maleta rígidaEstructura principal
        RouterCrear o gestionar la red
        SwitchConectar varios equipos por cable
        Raspberry PiNodo principal de servicios
        PantallaVisualización local
        SSD/HDDAlmacenamiento
        Fuente 12 VAlimentación principal
        Conversor 12 V a 5 VAlimentar Raspberry
        Caja de fusiblesProteger líneas DC
        VentiladoresRefrigeración
        Conectores de panelAcceso externo ordenado
        Cableado etiquetadoMantenimiento
        InterruptoresControl de encendido
        Voltímetro/amperímetroSupervisión de consumo

        No todos tienen por qué estar desde el primer día. La idea es empezar con una base sencilla y hacerla crecer.


        Qué quiero conseguir al final

        Al terminar el proyecto me gustaría tener una herramienta que pueda abrir en clase y utilizar directamente.

        Algo parecido a esto:

        Abrir maleta

        ├── Conectar alimentación
        ├── Encender router/switch/Raspberry
        ├── Levantar servicios
        ├── Conectar portátil
        ├── Acceder al panel o terminal
        └── Empezar la práctica

        Un laboratorio listo para trabajar.

        No sustituirá a Proxmox, VirtualBox, Docker o las máquinas virtuales, pero sí puede complementarlas muy bien. Aporta algo físico, visible y tangible, que ayuda mucho cuando se explican redes, sistemas y seguridad.


        Por qué merece la pena documentarlo

        Este tipo de proyectos tienen un valor especial porque mezclan muchas áreas:

        • hardware;
        • redes;
        • sistemas;
        • electricidad básica;
        • Linux;
        • documentación;
        • seguridad;
        • automatización;
        • diseño;
        • resolución de problemas.

        Es exactamente el tipo de proyecto que permite enseñar que la informática real no está formada por piezas aisladas. Todo se conecta con todo.

        Un router no es solo un aparato con antenas.
        Una Raspberry no es solo una placa pequeña.
        Un switch no es solo una caja con puertos.
        Una fuente de alimentación no es un detalle secundario.
        Y una buena documentación no es un trámite: es lo que permite entender, mantener y mejorar el sistema.


        Próximos pasos

        En las siguientes entradas iré publicando el avance del proyecto.

        Algunos de los próximos temas serán:

        • elección de la maleta;
        • diseño de la distribución interna;
        • elección de la fuente de alimentación;
        • montaje de la caja de fusibles;
        • conexión del router y el switch;
        • alimentación de la Raspberry;
        • integración de pantalla;
        • montaje del almacenamiento;
        • ventilación;
        • primeras pruebas de red;
        • primeras prácticas de ciberseguridad.

        La idea es que este artículo sea el punto de partida de una serie. No quiero presentar solo el resultado final, sino todo el camino.


        Conclusión

        Este proyecto nace de una necesidad muy concreta: disponer de un laboratorio móvil, compacto y reutilizable para trabajar redes, sistemas y ciberseguridad de una forma más práctica y visual.

        Todavía está en construcción. Algunas decisiones cambiarán, aparecerán problemas y seguramente habrá que rediseñar partes del montaje. Pero precisamente eso es lo interesante: convertir el proceso en aprendizaje.

        A partir de aquí comienza la construcción del Laboratorio Móvil de Ciberseguridad.

        Un proyecto para aprender, probar, equivocarse, mejorar y, sobre todo, llevar la práctica técnica un paso más allá.

        Especificaciones para Montaje de Maleta-Laboratorio Electrónica

        ElementoCategoríaVoltaje RequeridoAmperaje/PotenciaCantidadFunción
        Fuente de alimentación AC/DC (Kingwen o similar)Alimentación DCEntrada: 230 V AC12 V DC / 10 A – 20 A (120 W – 240 W)1Fuente principal para alimentar los dispositivos internos
        Raspberry Pi 4/5Cómputo5 V DC3 A – 5 A (15 W – 25 W)Según diseñoNodo de computación principal
        RouterRed12 V DC (típico)1 A – 2 A1Gestión de red y conectividad
        Switch GigabitRed12 V DC (o 9 V / 5 V)0.6 A – 1 A1Interconexión de los dispositivos de red
        Conversor DC-DC BuckAlimentación DCEntrada: 12 V / Salida: 5 V3 A – 5 A1 por RaspberryReducir el voltaje de 12 V a 5 V para alimentar la Raspberry Pi
        Caja de fusibles DC (Blade)Seguridad12 V DCSoporte multi-vía1Protección individual de líneas (2 A para router, 3 A para RPi)
        Entrada IEC C14 con interruptor y fusibleAlimentación AC230 V ACProtección por fusible1Punto de entrada único de corriente exterior para la maleta
        Enchufe AC schuko / panelAlimentación AC230 V ACSegún cargador de portátil1Conexión interna para un ordenador portátil
        Barra de distribución (Negativos)Alimentación DC12 V DCSegún carga total1Organización de los retornos de masa y negativos
        Cable eléctrico flexible 1.5 mm2 – 2.5 mm2Cableado12 V DCLínea principalVarios metrosCableado de alimentación desde la fuente a la distribución (evita caídas de tensión)
        Cable eléctrico flexible 0.75 mm2Cableado12 V DCLíneas de dispositivosVarios metrosConexión secundaria para router, switch y conversores
        Cable 3 x 1.5 mm2 homologadoCableado230 V ACAlta tensiónVarios metrosConexión segura de entrada IEC y enchufe para portátil
        Ventiladores 12 VClimatización12 V DC2 W – 5 W1 o 2Extracción de calor y ventilación forzada para evitar sobrecalentamientos
        Maleta rígidaEstructuraN/AN/A1Carcasa y base del montaje del laboratorio
        Placa interior de montajeEstructuraN/AN/A1Superficie para el anclaje y atornillado de todos los componentes