Disquetera no detecta cambio de disco, un error antiguo que no era de hardware, si no de software (DRIVPARM)

En mi viejo IBM PS/1, desde que lo tengo que me había encontrado con un tedioso problema. Resulta que al encenderlo e insertar un disquete, en cualquier unidad ya sea  de 3 1/2 o 5 1/4 el sistema operativo leía el contenido correctamente.


Pero si cambiaba el disco por otro al volver a leer su contenido, me encontraba que el sistema operativo volvía a listarme el mismo árbol de directorios.

Suposiciones

1) Pensé que el problema era de hardware,  lo que supuse es que la disquetera tenía problemas en los sensores debido a que el computador fue salvado de un centro de reciclaje y se encontraba muy pero muy sucio, con polvo metálico debido que compraban chatarra y había mucho polvo de oxido en todos lados. 

En este antiguo post https://loqueseaqueaprenda.blogspot.com/2020/10/como-reparar-disquetera-que-no-detecta.html, desarmé completa la disquetera, desoldé los sensores mecánicos (funcionaban por medio de switch, en comparación a la mayoría de las unidades de disco flexible que funcionan con sensores ópticos), luego de toda la limpieza también realicé ajuste de alineación de cabezales.

Luego de todo esto, el problema siguió, probé con otra disquetera que sabía que funcionaba, por lo que por pensé que el problema estaba en el cable.

2) Revisé la documentación del protocolo para saber como funcionaba la lógica de cambio de disco.

En el siguiente manual (Brother-Dp-525) página 63 se explica el flujo de pulsos entre el controlador (microchip) y la unidad (disquetera).

La señal de cambio de disco se comunica a través del pin 34:


Tomé mi multímetro y comencé medir la continuidad de cada uno de los cables, medí si existía continuidad y también corto circuito entre los pares cercanos, hasta ahí todo bien, el cable está impecable.

Luego de eso tomé el osciloscopio y medí el flujo de trabajo del pin 34, he corroborado que la disquetera está comunicando correctamente la señal de cambio de disco.

Quité la placa madre del gabinete y comencé a seguir la señal del pin 34, tras hacer esto me di cuenta que el chip controlador de la disquetera es el UM82C863F y la señal de cambio de disco (/DSKCHG) esta llegando correctamente al pin del microchip.


3) Tercera suposición, el microchip del controlador anterior está dañado y la única forma de solucionar este problema es cambiando el chip, o conseguir una tarjeta FDD con interfaz ISA, soluciones que a día de hoy son como buscar una aguja en un pajar.

Acepté que el chip estaba malo y cada vez que necesitaba instalar algún programa que utilizara más de un disco, copiaba los archivos al disco duro, y reiniciaba el pc por cada disco, y luego al terminar hacía la instalación desde el disco duro, realmente un procedimiento muy tedioso.

Revancha

Tras un año, estuve copiando algunos discos para un amigo, y volví a encontrarme con este horrible problema, tenía que reiniciar el equipo por cada disco que quería copiar.

Si, tras volver a la carga y empezar a googlear me percaté que este problema ya estaba declarado por Microsoft:

https://jeffpar.github.io/kbarchive/kb/096/Q96756/


Según Microsoft el error se debe a que el sistema utiliza el 'volumen ID' para detectar el cambio de disco y dependiendo del sistema operativo donde se le dio el formato podría no ir esta información provocando que el sistema no sea capaz de detectar el cambio. 

Hasta que me di cuenta de un gran detalle:

El sistema operativo si detectaba el cambio de disco, de hecho mostraba correctamente el Volumen ID, sin embargo el listado de archivos no se actualizaba.

El error siempre fue por software

El controlador lógico si le informaba al sistema operativo que había un disco distinto, sin embargo es el sistema operativo (MS-DOS) que por algún extraño motivo está usando una especie de caché para devolver el árbol de directorios.

Googleando nuevamente encontré este grandioso articulo perdido en el tiempo:


En este artículo se indica que usando el comando DRIVPARM puede solucionarse el problema. Y justamente así, he agregado las configuraciones correspondientes en mi archivo CONFIG.SYS

DRIVPARM=/D:0 /F:7

DRIVPARM=/D:1 F:1




Conclusión

Al parecer este problema solo afecta a máquinas IBM PS/1 y PS/2 con sistemas operativos MS-DOS, ya que hice la prueba instalando PC-DOS (de IBM) y no es necesario agregar esta configuración, al parecer con el sistema operativo de IBM funciona bien, esto significaría que es un problema de los drivers (controladores de software) que inluye MS-DOS y que genera incompatibilidad en estos equipos en particular, pero sin embargo se puede solucionar con una simple linea de texto.


Comentarios