Hardware abierto para MSX
MSX-SDF-1
Un kit de desarrollo de I/O para MSX, con un lector de tarjetas SD como primer proyecto
Un cartucho abierto y experimental: un microcontrolador asomado al bus del MSX, una ROM de 16 KB del lado del Z80 y media placa de islas perforadas para montar lo que tu proyecto necesite. Su primer proyecto —y lo único terminado hoy— le da a cualquier MSX una disquetera: monta imágenes de disco .DSK guardadas en una tarjeta SD, y la máquina las ve como si fueran una unidad real.
Está pensado para que se pueda armar en casa. Todos los integrados son THT y se consiguen en cualquier casa de electrónica — un ATmega328P, una EEPROM y tres chips de la serie 74. Sin GAL, sin CPLD, sin nada que haya que programar con herramientas raras.
- Prototipo · rev1
- MSX1 en adelante
- Componentes THT
- Área de experimentación
- Licencia MIT
Cara superior de la rev1, generada a partir de los Gerbers del repositorio.
Antes que nada
Esto es un prototipo. Todavía no armes uno.
La rev1 de la placa está fabricada y tiene errores conocidos. Funciona, pero sólo después de siete correcciones a mano sobre el cobre: cortes de pista, resistencias soldadas al aire y algunos puentes. No la recomiendo salvo que quieras meterte en eso a sabiendas, con el documento de correcciones al lado.
La rev2 va a traer la mayoría de esos problemas resueltos de fábrica. Si lo que querés es una placa para armar y usar, esperala.
Uso
Cómo se usa
Una tarjeta SD con imágenes de disco adentro, el cartucho en la ranura, la máquina apagada. Encendés, y el MSX arranca con disquetera: MSX-DOS, DIR, COPY, los programas de siempre. No hay menú que aprender ni driver que cargar — para la máquina es una unidad de disco más.
Lo que ve el MSX es una disquetera de 720 KB, doble cara y doble densidad. Cualquier imagen .DSK de ese formato anda, que es el formato en el que circula la mayor parte del software.
Hoy el firmware monta dos imágenes fijas por nombre y contesta como si hubiera dos unidades. Poder elegir la imagen desde la máquina —con botones, o con un menú en pantalla— es lo próximo, y el hardware para eso ya está en la placa.
- Compatibilidad
- MSX1 en adelante. En el slot aparece como un Disk ROM común.
- Formato
- Imágenes .DSK de 720 KB — 3½", doble cara y doble densidad.
- Tarjeta
- microSD formateada en FAT, en un módulo enchufado al header de la placa.
- Unidades
- Dos, hoy con nombres de archivo fijos. El selector de imágenes está pendiente.
Arquitectura
Cómo funciona
Para el MSX no hay nada nuevo: en el slot aparece un Disk ROM común, con la tabla de saltos de siempre —DSKIO, DSKCHG, GETDPB—. Esa ROM vive en la EEPROM del cartucho y es código Z80.
Lo que cambia es de dónde salen los sectores. En vez de manejar un controlador de disquetera, el driver escribe comandos y datos en dos puertos de I/O —0x00 para datos, 0x01 para comandos— y del otro lado los recibe el ATmega328P, que hace el trabajo real: habla SPI con la tarjeta, abre el archivo .DSK y devuelve los 512 bytes del sector pedido.
El truco está en la sincronización. Los dos 74LS138 decodifican el acceso a esos puertos y, con la misma señal, bajan /WAIT: el Z80 queda congelado en mitad del ciclo hasta que el ATmega termina y lo libera. No hay polling ni suposiciones de tiempo — la máquina espera lo que haga falta, y funciona igual a 3,58 MHz que en una turbo.
Componentes
Qué lleva la placa
- U1 · W27C512
- EEPROM paralela de 64 KB. Guarda el Disk ROM de 16 KB del cartucho.
- U3 · ATmega328P
- El cerebro. Bus del MSX de un lado, SPI y tarjeta SD del otro. Corre a 20 MHz.
- U2 · 74LS245
- Buffer bidireccional del bus de datos entre el MSX y el micro.
- U4 · U5 · 2 × 74LS138
- Decodifican los puertos 0x00–0x01 y generan la señal de /WAIT.
- H1 · Header de 10 pines
- Módulo de tarjeta SD más expansión: SPI, I²C y dos GPIO libres.
- CON1 · Conector de cartucho
- 50 contactos en el borde de la placa, con el formato de cartucho estándar.
Cara superior
Cara inferior
La idea
Nació como lectora de SD. Terminó siendo un kit de desarrollo.
El proyecto empezó con un objetivo concreto y chico: que un MSX pudiera leer imágenes de disco desde una tarjeta SD. Eso es lo que la placa hace hoy, y es lo único que está probado.
Pero con el diseño terminado quedó claro que el hardware no tiene nada de específico. Lo que hay en el cartucho es un microcontrolador asomado al bus del MSX por dos puertos de I/O, una ROM de 16 KB para poner rutinas del lado del Z80, y un protocolo byte a byte entre los dos. El disco es apenas un juego de comandos montado encima de eso.
Cambiando la ROM y el firmware, y dejando el resto intacto —el mismo decodificador, el mismo handshake, el mismo formato de comando y respuesta— la misma placa puede ser otra cosa. Un puerto serie. Una interfaz de sensores. Un puente hacia un micro con WiFi. Cada uso es un perfil: su firmware, su ROM, y lo que necesite en hardware.
Por eso media placa es un área de islas perforadas. No es relleno ni espacio sobrante: es donde se arma lo que cada perfil necesite, colgado del I²C y del SPI que ya salen por el header. El ATmega no tiene que traer la periferia adentro — tiene que saber hablarle. Visto así, el SDF-1 es menos un periférico terminado y más un kit de desarrollo: la placa pone la base, el proyecto lo pone cada uno.
La prueba está en la placa misma: la tarjeta SD no vive en el PCB, es un módulo colgado del header, igual que lo estaría un UART o un ESP32. El drive ya es un perfil montado sobre una placa genérica.
Y los perfiles se combinan o se quedan solos. Un armado sin tarjeta SD no es una versión mutilada: es otro producto. Se puede poblar sólo lo que hace falta para un RS-232, con su propia ROM y sin una línea de código de disco.
Drive de disco
El perfil que existe: imágenes .DSK desde la tarjeta, y el MSX convencido de que tiene disquetera.
Puerto serie RS-232
En el micro no queda UART libre, y no hace falta: un UART por I²C más el conversor de niveles se arman en el área universal. El firmware sólo agrega los comandos.
Puente a un micro con WiFi
Un ESP32 en el área universal, enlazado por SPI o I²C. Es el camino más corto de un MSX a una red moderna.
Sensores y periferia
Reloj, memoria, expansores de puertos, sensores. Todo lo que hable I²C o SPI entra sin tocar el diseño.
Todo esto es dirección de diseño, no funcionalidad existente. La placa permite estos usos; todavía no los tiene. Lo único probado hoy es el lector de SD.
Extensiones de BASIC
El Disk ROM ya tiene el gancho que el BASIC usa para reconocer comandos nuevos, y en el bloque de la ROM quedan unos 2 KB libres. Ahí entran comandos propios para manejar el I²C y los pines desde el intérprete, sin salir del BASIC.
Un CALL I2CSCAN que liste las direcciones que contestan en el bus es el primer paso natural: se prueba sin hardware externo y da un resultado visible en pantalla. Después vienen la lectura y la escritura de registros, que es lo que necesitan los chips de verdad — un reloj, una memoria, un sensor.
Nada de esto está implementado todavía. Es el plan, y está acá para que se entienda hacia dónde va el proyecto — no para que nadie lo espere en la placa de hoy.
10 REM quien contesta en el bus
20 CALL I2CSCAN
30 REM escribir un registro
40 CALL I2CWR(&H68, &H00, &H30)
50 REM mover un pin
60 CALL GPIOW(1, 1)Cómo se verían los comandos. Sintaxis propuesta, todavía sin implementar.
El header H1
El header de diez pines no es sólo el zócalo del módulo SD: lleva el bus SPI completo, el I²C del ATmega y dos GPIO que no usa nadie. El hardware para todo lo de arriba ya está puesto y esperando firmware.
En la rev1 el header no tiene serigrafía. Este es el pinout que sale del netlist.
| Pin | Señal | Uso |
|---|---|---|
| 1 | VCC | Alimentación · 5 V |
| 2 | SCK | Reloj de SPI |
| 3 | MISO | SPI · entrada de datos |
| 4 | MOSI | SPI · salida de datos |
| 5 | CS | Chip select de la tarjeta SD |
| 6 | PB1 | GPIO libre |
| 7 | PB0 | GPIO libre |
| 8 | SDA | I²C · datos |
| 9 | SCL | I²C · reloj |
| 10 | GND | Masa |
Diseño
Las siete decisiones que lo definen
El truco de fondo —bajar el /WAIT del Z80 con la misma señal que decodifica el puerto, y contestar con un microcontrolador mientras la máquina espera congelada a mitad del ciclo— lo tomé del Virtual MSX Disk Drive que Raul publicó en 2013. De ahí en más, todo lo demás está resuelto acá, y es donde está el trabajo.
Anda solo, sin una PC atrás
En el original el Arduino no guarda nada: cuelga del USB de una PC y un script de Python le pasa los sectores. Acá el ATmega lee el .DSK él mismo, de una microSD por SPI. El cartucho se enchufa y funciona con la máquina sola.
Decodificación completa, no una ventana
El original engancha cualquier puerto por debajo de 0x20. Acá dos 74LS138 decodifican A7..A1 y dejan seleccionados sólo 0x00 y 0x01. Las otras siete salidas quedan libres: mover el par de puertos es rutear otra, y en la rev2 pasa a ser un jumper.
Dos puertos, o mejor dicho dos registros
A0 no es selección de chip: es el selector de registro. 0x00 son los datos, y es bidireccional — el mismo registro lleva los 512 bytes que el MSX escribe y los 512 que lee, con /RD resolviendo la dirección. 0x01 es el otro lado del diálogo, y es asimétrico a propósito: escribirlo es ejecutar un comando, leerlo es preguntar el estado — ocupado, error, cuántos bytes hay — sin robarle bytes al canal de datos.
Las cuatro líneas que van al micro
El post muestra el esquemático en fotos pero nunca dice cuáles son. Además de los 8 bits de datos, al ATmega tienen que llegar exactamente cuatro: la selección decodificada (que lo despierta por PCINT), A0, /RD, y una salida para soltar el /WAIT.
El /WAIT, en colector abierto
/WAIT es una línea wired-OR que comparten todos los cartuchos. Atacarla con una salida totem-pole es pelearse con cualquier otra placa. Acá sale por una NAND de colector abierto: el cartucho sólo puede tirarla a bajo, nunca forzarla a alto.
El mismo micro que un Arduino, pero a 20 MHz
No hay una placa Arduino adentro del cartucho: es el ATmega328P pelado, soldado al PCB, con su cristal y nada más. Y ese cristal es de 20 MHz en vez de 16 — un 25 % más de instrucciones justo en la ventana en la que el Z80 está congelado esperando la respuesta.
El código, publicado y explicado
El original cerraba pidiendo disculpas por no documentar, y un link a Google Drive. Acá están las dos mitades en el repositorio, bajo MIT, con el esquemático, los Gerbers, la lista de componentes y las correcciones de la rev1.
Estado
Dónde está el proyecto
El firmware implementa lectura y escritura de sectores contra imágenes .DSK en la tarjeta, que es lo que hace falta para arrancar MSX-DOS y trabajar. Las demás llamadas del Disk ROM todavía responden con valores fijos desde la ROM.
Las dos mitades del cartucho —el driver de disco en Z80 y el firmware del micro— están en el repositorio, junto con el esquemático, la lista de componentes y las correcciones de la rev1. Ahí está el detalle técnico y todo lo que hace falta para reproducirla.
- Hardware
- Rev1 fabricada, con errores conocidos y siete correcciones a mano documentadas. La rev2 los va a traer resueltos de fábrica.
- Firmware
- Lectura y escritura de sectores andando. Hoy monta dos nombres de archivo fijos: falta el selector de imágenes.
- Alcance
- Lo único probado es el lector de SD. Los perfiles, las extensiones de BASIC y el bootloader son dirección de diseño, no funcionalidad existente.
Hacia dónde va
Ordenado por lo que habilita, no por dificultad. Cada paso apoya al siguiente.
-
Firmware más rápido
Sacar el sistema de archivos de la ruta crítica y guardar el sector en la RAM del micro. Es la mayor ganancia por esfuerzo que queda pendiente.
-
Protocolo v2
Un registro de estado de verdad, para que el MSX sepa si el micro está ocupado, si hubo error y cuántos bytes tiene para leer. Habilita todo lo demás.
-
Manejar las imágenes desde la máquina
Montar, listar y desmontar los .DSK con comandos propios. Son las primeras extensiones de BASIC, antes que las de periferia.
-
I²C, SPI y GPIO desde BASIC
Los comandos de periferia, empezando por el escaneo del bus I²C — el primero que se puede probar sin nada conectado.
-
Rev2 del PCB
Las correcciones de la rev1 resueltas de fábrica, header de programación para no sacar el chip, botones, y jumpers para elegir los puertos de I/O.
-
Bootloader propio
Que la placa lea su firmware de la propia tarjeta. Cambiar de perfil pasa a ser copiar un archivo.
-
La placa como kit de desarrollo
Separar el núcleo del protocolo de la tabla de comandos de cada perfil, y publicar cada personalidad como una receta completa: qué se suelda, qué firmware, qué ROM.