La emualción de disco del MegaSCSI es la mejor que conozco. Hasta
ahora
no me he encontrado con ningún programa que usando rutinas 'standar' no
funcione. El fallo que has cometido en el SBB (y en el resto de programas)
es suponer que determinados puertos contienen determinados valores. No
puedes suponer (o dar por seguro) que el registro C del PPI va a mantener
siempre el mismo valor. Os mando una versión corregida que funciona
perfectamente con la emulación de disco del MEGA-SCSI.
¡¡¡BRILLANTE!!! 8:D
Pues ahora déjame decirte el fallo que TU has cometido:
Suponer que soy gilipollas.
Has parcheado y distribuido sin aviso ni permiso mi código para corregir un
defecto que tiene la maravillosa "emuAlción" de disco del Mega-SCSI y que
me quieres endosar a mí, y encima en público.
Tsk, tsk. Eso es poco elegante. Sobre todo para con una dama 8;)
En primer lugar, puedo suponer PERFECTAMENTE que el valor del registro C
del PPI (el cual se encarga exclusivamente del teclado, cassette y leds) va
a permanecer eternamente inalterado mientras las interrupciones estén
deshabilitadas INCLUSO A NIVEL DE VDP, el vector #38 apunte a mi propia
rutina, y las únicas rutinas externas que llame sólo tengan que ver con
gestión de disco.
Dichas rutinas no tienen que tocar el registro C del PPI absolutamente para
nada. Pero incluso en el remotisísimo supuesto que tuvieran que hacerlo,
con el fin de cumplir la sagrada ley que figura en la primera página de
toda referencia de hardware desde tiempos de la VCS, deberían enmascarar
los bits que no utilizan.
Por el momento no he tenido el placer de conocer ninguna rutina de disco
que utilice explícitamente el teclado, los LEDs, y ni mucho menos el
CASSETTE.
La única rutina en el MSX que tiene INDULGENCIA PLENARIA y BULA PONTIFICIA
para tocar tal puerto como le venga en gana y dejar el resultado que le
apetezca sin dar cuentas a nadie es el handler del teclado que se ejecuta
en la interrupcion de cuadro, la cual tiene incluso permiso para manosear
el VDP.
¿Que pasa entonces? Pues que la maravillosa emulación Mega-SCSI debe
llamar
de manera herética e impía tal handler con a saber qué oscuro cometido,
ya
sea mediante salto directo o interrupción, lo que además de altercar mi
software, podría tener devastadoras consecuencias en según qué entornos
lógicos (¡no quiero ni pensarlo!).
Si en tu opinión las suposiciones que hago son falsas entonces tendrías
que
extender tal profilaxis al PSG, VDP, etc., y cambiar de modo de vídeo y
recargar la paleta cada vez que llames a una rutina externa (SEA CUAL SEA)
que no declare explícitamente que guarda estos ajustes, aunque se trate de
sacar un byte por el puerto de impresora.
Quién sabe, quizá en versiones futuras de la BIOS si hay error en el
Centronics te podría aparecer perfectamente un requester en SCREEN 0 con un
pitido, o peor aun, en SCREEN 12 con un SAMPLE 8;)
¡Y entonces ya nos podemos ir todas al PRYCA a comprar condones! (^_^)
Una rutina de disco puede *perfectamente* habilitar las interrupciones,
incluso instalar su propio servidor de interrupción, pero de ahi a forzar
la ejecución de PRECISAMENTE *ESE* handler en concreto, pasándose por el
forro el contenido de la #38...
No me digas que en realidad lo que pasa es que la emulación es controlable
por teclado (no lo sé, no la he probado), O QUE EMULA EL LED DEL DISKETTE
CON EL DEL CAPS LOCK, porque si es así y no guarda el PPI-C se salta a la
torera el PRIMER principio de la emulación: LA TRANSPARENCIA.
Ya sabes que yo soy de las que no supone cosas a la ligera, nunca toco bits
reservados, no leo registros de sólo escritura, etc., pero joer, hay cosas
de sentido común. Recuerda que al principio incluso sacaba las direcciones
de los puertos del VDP de la ROM (!).
Soy muy estricta con la compatibilidad y prueba de ello es que el SBB y la
promo del Moskow 2024 han funcionado perfectamente a la primera incluso en
2+ y TR japonescos con configuraciones exóticas teniendo como maquinaria de
desarrollo sólo un 8250 y un F700 (aunque Felipe aun no esté del todo muy
convencido 8;)
Ahora déjame decirte también porqué TODOS los demás programas
funcionan con
esa emulación:
Porque se acostumbra a reescribir puertos que no cambian, salvar registros
que no se modifican, deshabilitar interrupciones que no ocurren NUNCA,
cargar datos que YA ESTAN EN MEMORIA, esperar a comandos VDP que hace
CUADROS que han acabado...
Vamos, alegrar la vida a los programadores de emuladores, que se creen
que su producto funciona 8:)
¿Qué rutina usas para detener la unidad? No todas las DiskROM son
iguales, por lo que no siempre es 'legal' para las unidades.
Este asunto ya lo discutí contigo hace tiempo después de largas
investigaciones en la lista holandesca. Llegué a la conclusión de que la
mejor manera de llamar a la DiskROM para parar el motor cumpliendo todas
las condiciones y sin salirse de la legalidad era como lo hago en el SBB.
Funciona perfectamente incluso con el ESE-RAM y el Mega-SCSI.
Te lo expliqué y no encontraste ningún problema. No me irás a meter
ahora
otro parche que restaure el sistema y llame 255 veces a "cierta rutinita",
¿no? 8;) 8;) 8;)
Hay otro entry-point en la DiskROM para parar las unidades PERO ese sí que
no es oficial, así que shhhhhh.... 8;x
APENDICE: EFECTO NINJA Y2K (^_^)/
Si hay alguien que -para empezar el Y2K con el pie siniestro- en un
arrebato ha profanado su diskette original del SBB con la version apócrifa
del PLAY.COM de Manuel Pazos, Matra Playtech informa de que disponemos de
un servicio 24h gratuito de redención por e-mail.
Besitos.
Mark 2
"Suponer que soy gilipollas" aparece por cortesía de S.T.A.R., Ltd.
"Sex Bomb Bunny", el logo SBB y "Moskow 2024" son marcas registradas de
Matra Corp.
"Comprar condones en el PRYCA" es un comportamiento registrado de Olga S.A.
"Pie siniestro" es un filme registrado de Bizarre Films, S.A.
Otras marcas pueden estar registradas (o no) por sus respectivos autores.
