Hola JAM!
El único beneficio que tiene usar la Bios es este, que
accederemos al puerto correcto donde se encuentra el PPI.
Pero hay que entender que la BIOS es un conjunto de rutinas
que acceden al hard de forma que quede garantizada la
compatibilidad en el sistema. Si la propia BIOS no restaura
ese registro, nuestro sentido común nos obliga a pensar
que no podemos nunca suponer que es inalterable "solo".
Exacto, para acceder a los puertos Hardware correctos.
Sin envargo, sigo pensando que el razonamiento de que no hace
falta restaurar el PPI-C por un programa parcheador de la DiskROM
porque la Bios no lo hace, es muy arriesgado.
El hecho de que se restaure el PPI-C se debe a la naturaleza
de la rutina, Las Rutinas de la Bios están hechas para que NADIE
trabaje con el Hardware directamente, por lo cual es lógico
pensar que nadie trabajará con el puerto $AA, lo cual nos lleva
a que no es necesario restaurarlo. Por esto no lo restaura.
Sin envargo, la naturaleza del MegaSCSI es pasar desapercivido
a los programas ajenos a él, ya que por lógica, ellos no saben
que él está ahí. Por eso si modifica el RGB del borde, cuando termine
lo que ha de hacer es dejarlo como estaba, si modifica el PSG, cuando
termine ha de dejarlo como estaba, por la misma regla de tres, cuando
modifique el PPI-C ha de dejarlo como estaba.
Yo creo que no se trata de que no hay que restaurarlo por que
la Bios no lo hace, sino que debe restaurarlo por ser un Parche.
Es lo que llevo diciendo desde el principio y nade dice nada
sobre esta teoria.
¿Porque el Emulador de la MegaSCSI si DEBE de restaurarlo?
Pues por la naturaleza de su objetivo, PARCHEAR unas funciones
de la DiskROM para poder simular un disquet físico en el Disco >duro.
Al tratarse de un Parche DEBE ser lo más trasparente posible,
o sinó, la cagará como hace con el SBB.
Lo que es el parche de las rutinas de disco es transparente en
sí, lo que falla es ajeno a dichos parches. Es el teclado, y
no restaura un valor que no tiene por qué restaurar.
Pues más a mi favor. Nadie espera que tras llamar a una rutina
de disco le vayan a tocar el PPI, el PSG, el VDP, etc... Lo lógico
es pensar que solo usará los controladores de disco.
Vamos a ver, apuesto lo que sea que si MK-II llega a probar el
SBB con el MegaSCSI y ve que no funciona, seguro que habría puesto
remedio.
Sí, eso lo sé. Pero, ojo, que yo no estoy hablando a estas
alturas del caso del SBB, ni digo que MkII se haya equivocado.
El SBB está hecho para que corra en un MSX de forma REAL y que
no falle en ninguna máquina (de hecho no lo hace), y por eso
el problema del EP.COM no es achacable a ella.
Disculpa por creer que te referias al SBB.
Pero, si yo tuviera que ponerme a hacer un juego, pues usaría
la BIOS o no supondría que el PPI-C ha sido restaurado por el parche del
EP.COM
Es que tu esto no lo sabes, quien te dice a tí que una llamada a la
diskROM te va a modificar el PPI-C, o el VDP, o el PSG... pero si
nisiquiera sabes que la DiskROM está parcheada.
Si tu haces un juego, no vas a estar pensando en que te
pueden parcher tu juego por todas partes. Son ellos, los
parcheadores los que se tienen que preocupar en no afectar
a tu programa.
en el caso del SBB MK-II tiene el control total del MSX (en todos >los
niveles) Es absurdo que esté TODO el RATO actualizando el
Ahí es donde yo programaría de otra forma: nunca supondría que
voy a tener el control total del MSX (porque nunca se sabe).
Pero, ojo, es como lo haría yo, y reconozco que ella no se ha
equivocado.
Respeto tu forma de programar, pero si yo quiero tener el control
del MSX por determinados motivos pienso que lo tengo y lo aprovecho,
sino no tiene sentido querer tenerlo.
En el caso que no lo tengas, por la cuenta que le trae al
emulador o lo que sea, pues se tendrá que molestar en respetar
al programa emulado para que no falle.
Y por cierto ¿Quien se ha saltado las reglas? El SBB trabaja
según las reglas, pero el MegaSCSI se ha saltado las reglas de
Ya te digo, no hablaba en concreto del SBB.
Perdona por creer que te referias al SBB.
De todas formas te cito traducido lo que dice el Technical Handbook
de ASCII Corp.:
"[...]
El propósito de la BIOS es separar el hardware del software
y hacer el software todavía válido si el hardware cambia". Los
programas que vayan a ser vendidos y que hagan uso de entradas/salidas
deben usar la BIOS (excepto para el VDP)"
De aquí se sacan varias conclusiones:
a) Que ASCII dice que hay que usar la BIOS si queremos hacer
software comercial
b) Que como bien dice ASCII, el hardware puede cambiar aunque
la compatibilidad MSX siga siendo 100% a través de la BIOS.
Imagina que sale un modelo de MSX en el que el PPI-C cambia
por cualquier cuestión que ahora se nos escapase. Ese aparato
llevaría escrita la BIOS para poder leer el teclado sin ningún
tipo de problema, pero si accediéramos por puertos, nos
podríamos encontrar con que ese hard funciona de forma
distinta a lo esperado. Sin embargo, la máquina seguiría siendo
un MSX en toda regla, pero nuestro programa no funcionaría.
Pero esto es solo a nivel de puertos Hardware. Yo creo que tiene
poco que ver en relación a nuestro problema. (Que un parche de la
DiskROM restaure todo lo que él modifique, en este caso el PPI-C)
Cuando usas un emulador de pecera y un juego no va, ¿de quien >es la
culpa? del juego o del emulador.
En unos casos del emulador, y en otros será del juego.
Vaya, me has sorprendido.
Me puedes poner un ejemplo que el emulador tenga la culpa.
Porque no se me ocurre ninguno.
Como conclusion yo pienso que:
Un programa que parchee cualquier rutina debe restaurar todo lo
que modifique para ser lo mas transparente posible y no tener
conflictos con los programas que no saben que él está ahí.
La conclusión que yo no comparto es:
El MegaSCSI, basandose en que todos los programas parcheados
usarán la Bios para leer el teclado, llega a la concusión de que no
es necesario restaurar el PPI-C ya que la Bios lo inicializa siempre.
Las dos teorias son correctas, pero la primera es la más fiable.
¿Pero porque? La mayoría de programadores no usan la Bios para
leer el teclado, sino que acceden a los puertos directamente, lo cual
hace que a veces no haga falta volver a reinicializar el PPI-C con el
mismo valor, ya que sabemos que no hay ningún progama externo que lo
modifique.
Yo creo que el autor del MegaSCSI debería de haber tenido esto
en cuenta y optar por la primera conclusión. Ya que tratandose de
un parche lo mejor es ir sobre seguro y no confiar en que todo el
mundo usará la Bios para leer el teclado.
Por cierto, alguien puede mirar si el emulador de disco del
MegaSCSI usa la Bios para leer el teclado???
Por cierto, otra cosa, en tu futuro LoadROM harás que pueda
parchear ciertos juegos MegaROM para que funcionen correctamente
con poca RAM, te lo digo porque puedo ayudarte a encontrar todos
los lugares del MegaROM donde escribe en su mapper y saber cuales
son las únicas combinaciones posibles de bloques de 16Kb.
Eso lo puedo hacer yo, pero no me termina de convencer la idea.
¿De qué me sirve a mí saber cómo hacer el parcheo específico para
el megarom? Quien lo tiene que saber es el LOADROM, no yo. Y para
eso, habría que introducir la información específica para cada
ROM y podría ser brutal. Además, yo quiero que LOADROM siga
siendo "universal", que no tenga que "conocer" previamente
el .ROM para poder ejecutarlo. Porque para eso, ponemos las
versiones adaptadas por Martos y andando.
Ok, ya he leido tu otro mail sobre como funciona el LoadROM
y es un sistema muy bueno, ir creando las combinaciones de página
'sobre la marcha' no me había dado cuenta.
Saludos!
