Mi intención no era crear polémica, y creo que el tono de mi e-mail era
muy distinto al del tuyo. La gente que me conoce sabe que no suelo entrar en
polémicas. Pero bueno, año nuevo, vida nueva:
_ Defense ON
Ok
_ Alicatrapa ON
Syntax error
Ok
REM Perdón
_ Alikatrapa ON
Ok
¡¡¡BRILLANTE!!! 8:D
¡Gracias!
Pues ahora déjame decirte el fallo que TU has cometido:
Suponer que soy gilipollas.
Antes no lo pensaba, pero ahora...
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.
Perdona por distribuir tu código sin aviso ni permiso, pero creí que lo
importante era subsanar el error lo antes posible para que la gente pudiese
disfrutar del juego. Además, esa parte de código no vale mucho por si sola,
es decir, que no se puede jugar con sólo ese fichero. De todas formas, la
próxima vez que te corrija algo mandaré un 'patch'. Y sigo opinando que lo
que falla no es la emulación de disco, sino tu programa.
Tsk, tsk. Eso es poco elegante. Sobre todo para con una dama 8;)
¿Con una dama? Te lo he corregido a ti, no a Z-0.
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.
Te equivocas TOTALMENTE. Sigue leyendo...
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.
Y así es como lo hace el soft del MEGASCSI, dejando inalterados los bits
que no utiliza, que por cierto, es la forma correcta de hacerlo.
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.
¿No conoces ninguna? Yo te la presento: MkII-MegaSCSI, MegaSCSI-MkII
Muac, muac. Dos besitos y presentación realizada.
(Las rutinas de emulación de disco del MegaSCSI son un ejemplo, conozco
unas cuantas más que también lo hacen)
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.
Te vuelves a equivocar como viene siendo habitual. Dicha rutina preseva
el valor de los bits que no se deben tocar, y utiliza con total libertad el
resto.
¿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!).
Tu léxico me abruma, y reconozco que debido a mi ignorancia en ocasiones
me cuesta seguir tus erróneos razonamientos. Es más, he tenido que buscar
'apócrifa' en el diccionario.
El MegaSCSI no utiliza esa rutina para nada, no es necesario. Y no creo
que tuviese ningún problema en según que entornos lógicos. Aunque reconozco
que falla en entornos ilógicos como el tuyo.
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.
Yo no digo que sean falsa, digo que son erróneas.
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! (^_^)
Me parece que estás dramatizando tu error, pero bueno...
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...
Si has leido (y entendido) mis explicaciones anteriores, te darás cuenta
de que esto que dices no tiene ningún sentido.
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),
Efectivamente, eso es lo que hace. Por fin das en el clavo.
O QUE EMULA EL LED DEL DISKETTE
CON EL DEL CAPS LOCK,
Esto no lo hace, aunque hay programas (como algún cache de disco) que si
lo hacen.
porque si es así y no guarda el PPI-C se salta a la
torera el PRIMER principio de la emulación: LA TRANSPARENCIA.
Dime UN SOLO sitio donde ponga que el contenido del LSN del PPI-C hay
que guardarlo. Y si fuera así tu serías el primero en haber cometido otro
error, ya que no guardas dicho valor en tus programas.
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 (!).
Totalmente de acuerdo. Se que eres una persona muy metódica, y que pones
mucho interés y cuidado en lo que haces, y por ello te admiro.
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,
Yo no lo hago y funciona.
salvar registros que no se modifican,
Tampoco lo hago (al menos intencionadamente) y funciona.
deshabilitar interrupciones que no ocurren NUNCA,
¿Por ejemplo?
cargar datos que YA ESTAN EN MEMORIA,
¿...?
esperar a comandos VDP que hace
CUADROS que han acabado...
Cualquiera que programa decentemente el VDP sabe que basta con comprobar
un bit para saber si ha acabado o no.
Vamos, alegrar la vida a los programadores de emuladores, que se creen
que su producto funciona 8:)
Mejor aún, vamos a alegrar a todo el mundo haciendo programas que
funcionan.
¿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
Más bien te dije que te aseguraras de qué dispositivo estás parando, no
vaya a ser que se trate de algun 'controlador' de discos duros extraño y te
lleves una sorpresa.
otro parche que restaure el sistema y llame 255 veces a "cierta rutinita",
¿no? 8;) 8;) 8;)
No, ¿por qué? De hacerlo, lo haría bien.
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.
¡Yo¡ ¡Yo lo quiero! Si tienes por ahí una versión que funciona sin
problemas te agradecería que me la mandases.
Y si me lo permites, me gustaría darte un pequeño consejo. Aprende de
tus errores. Por lo que se ve te molesta mucho que te corrijan (y sobre todo
en público). Además, supongo que haya molestado que un pardillo como yo
corrija al mejor programador del mundo (según tus propias palabras). Yo soy
humano y me he equivocado muchas veces (esta puede ser una de ellas), y más
que me equivocaré, pero aprendo de mis errores y escucho a los demás.
Saludos a todos,
Manuel "El Ninja Malo" Pazos
