At 20:38 12/01/00 +0100, you wrote:
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.
Hombre .... Si el fabricante de la máquina, o ASCII lo hacen así,
es porque ellos dan por hecho que nunca podemos suponer cuál es
el valor que ahí hay. Si aplicamos nuestro sentido común, lo lógico es
basar nuestro criterio en lo que los creadores de la
máquina hacen ..... Mejor que ellos no conoce nadie la máquina!
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
Hasta ahí de acuerdo. Pero, el MegaSCSI está en su derecho de
suponer que todo programador comercial va a usar la BIOS, porque
así lo manda la norma. Hilando fino, y llevando esto a sus
últimas consecuencias, un programa que no use la BIOS (salvo en la
especificación detallada del VDP) NO es un programa MSX.
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.
Si yo te comprendo. Yo entiendo que una emulación/parche debe
ser lo más transparente posible. Pero al megascsi no se le puede
tachar de suponer que los programadores vamos a seguir siempre
las reglas (porque debería de ser así).
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.
Pero, es que yo no tengo ni por qué saber qué es ni cómo funciona
el registro PPI-C ! Yo tengo una bonita función #0141 de la BIOS que me
hace esto de forma transparente, y yo no tengo por
qué hacer esto de ninguna otra forma! ASCII me dice bien claro
que si hago soft comercial, debo hacerlo así.
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.
El MegaSCSI es 100% transparente mientras el programador haya
seguido las normas dictadas por ASCII.
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.
Por eso al final esto es una cuestión de gustos :)
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
No sólo a nivel de puertos. Un fabricante podría perfectamente hacer un MSX
con un chip totalmente distinto al 8255 pero que a través de la BIOS fuese
100% compatible. Si no usaras la BIOS, como el estándar dice, tu programa
NO sería compatible MSX, mientras que la máquina sería un MSX en toda regla.
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.
Pues cuando pones cualquier juego de TurboR y no va en RuMSX,
es porque el emulador está mal programado. Pero cuando pones
un juego de Topo que presupone que el subslot de la RAM es el 3
sobreel emulador BrMSX que por defecto lo tiene en el 2, entonces
el fallo es del juego. Ahí tienes un ejemplo de cada caso.
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í.
Mi matiz es que yo pienso que tiene que modificar todo aquello
de lo cuál el programador pueda tener consciencia. El PPI-C, en
teoría, no es una de esas cosas.
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.
Pues se lo puede permitir ya que en teoría el MegaSCSI no se
equivoca: hay que usar la BIOS siempre para garantizar compatibilidad.
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
Pues ESE es precisamente el problema. Y ojo, que yo no me libro
de pecado. Pero te aseguro que si hago un programa y en algún
momento falla por no haber usado la BIOS, seré consciente
de que la culpa es mía.
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.
¿Sabemos? Suponemos ;-)
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.
Bueno .... Eso es cierto. Podría haberlo hecho así: pero lo ha
hecho de la otra forma, y nos guste o no, no nos queda más remedio que
jodernos porque él lo ha hecho con pleno derecho.
Y eso de que la mayoría de los programadores acceden al puerto
directamente ..... Si eso de la mayoría fuese cierto, entonces
por extensión, la mayoría de los programas no funcionarían con
el EP.COM ..... Pero lo cierto es que en la practica, el 99% de
los programas funcionan perfectamente :)
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.
Pues sí. Deberíamos de felicitar a Trunks por ello. Es un genio :) Ese
programa tiene un meritazo. En el caso del TRLOAD, por ejemplo, la cosa es
más fácil, porque el programa aprovecha el
mapper de 8KB que tiene el TurboR. El LOADROM se las tiene
que ingeniar para usar las páginas de 16K de los mappers estándar. ;-)
Un saludo,
Jose Angel Morente (msxjam(_en_)crosswinds(_punto_)net)
*MSX DREAMS* (msxdreams(_en_)hotmail(_punto_)com)
¡Suscríbete a HispaMSX!
http://es.onelist.com/community/hispamsx
hispamsx-subscribe(_en_)onelist(_punto_)com
msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx
