Conectividad Dragon - PC

Avatar de Usuario
luiscoco
Mensajes: 2413
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 36 veces
Agradecimiento recibido: 57 veces
Contactar:

Re: Conectividad Dragon - PC

Mensajepor luiscoco » 14 May 2014 23:46

Último mensaje de la página anterior:

Algo que no entiendo bien es el camino que elegiste, si todas las funciones del DOS usan leer sector , escribir sector, y poco más, pienso que sólo interviniendo esa parte ya todos los comandos funcionarían, o no?

Avatar de Usuario
pser1
Mensajes: 2835
Registrado: 08 Dic 2012 18:34
Agradecido : 616 veces
Agradecimiento recibido: 744 veces

Re: Conectividad Dragon - PC

Mensajepor pser1 » 15 May 2014 00:26

Hola Luis,
DriveWire es un servidor de sectores, pero ésto a mi no me gusta.
A ver, tenemos dos máquinas, una super-rápida que es el PC y una que no llega a 1Mhz de velocidad, entonces ¿porqué cargar todo el trabajo al Dragón?
El PC puede hacerlo todo sin pestañear y mientras además reproduce música, descarga el correo, etc.
Leer y grabar un sector es muy simple, pero resulta que Dragón ha de saber qué sectores debe pedir de cada uno de los cuatro discos virtuales conectados, lo cual implica bajarse el directorio completo de cada uno y mantenerlo en memoria, ¿para qué? Hay juegos/programas que requieren casi toda la RAM así que no sé donde poner los directorios.
1 Pista = 18 sectores de 256 bytes = 4,5Kb para UN SOLO disco, si quieres que antes de cada comando el PC envíe el directorio entero, la carga de un juego puede eternizarse ya que después de desperdiciar este espacio, Dragón tiene que chuparse las entradas del directorio para encontrar el juego que queremos e ir solicitando sectores al PC, realmente NO me gusta mucho la idea.
Tal vez me he perdido en mi forma de verlo, por lo que agradecería que me indicaras como hacerlo dejando que el servidor en Java sea un simple servidor de sectores y Dragón le vaya ordenando lo que tiene que hacer ...
Por cierto sólo hay que interceptar un hook ($179-$17b) para todos los comandos que quiera implementar y sólo modificando $132-$133 intercepto todas las funciones.
Tanto unas como las otras simplemente tienen que recuperar una cadena y enviarla al PC, esperando luego respuesta ...

saludos
pere

Avatar de Usuario
pser1
Mensajes: 2835
Registrado: 08 Dic 2012 18:34
Agradecido : 616 veces
Agradecimiento recibido: 744 veces

Re: Conectividad Dragon - PC

Mensajepor pser1 » 15 May 2014 10:52

Le he estado dando vueltas a la posibilidad de interceptar solamente SREAD y SWRITE y, a pesar de no ver muy claro que puede aportar en operaciones como SAVE, PROTECT ON/OFF, KILL que al modificar una entrada de directorio pueden implicar modificar algunos segmentos de la FAT y posteriormente copiar sectores de la pista 20 a la 16.
Como entiendo que la idea sería pedir al PC que envíe un sector, que Dragón leerá sobre su buffer (para la unidad en cuestión) y luego tendrá que mover estos datos a memoria, por ejemplo para LOAD ó RUN. Me parece que esto va a ralentizar bastante el proceso.
Se podría tolerar este sistema si estuviéramos conectados a 57.600 bauds ó mejor a 115.200 bauds, pero la cruda realidad es que estamos a 19.200 (tercera y sexta parte respectivamente)
Como ya tengo el sistema de intercepción de comandos en marcha, espero que no me resulte muy complicado limitarlo a los SREAD y SWRITE hacia rutinas que sepan determinar el numero de sector de la unidad adecuada para solicitarlo al PC, guardarlo en el buffer correspondiente y devolver control al D.O.S.
Habrá que añadir dos comandos nuevos en el PC que forzosamente deben llegar vía puerto serie, uno para SREAD y otro para SWRITE.
Veremos que pasa con el experimento.
En el peor caso podría usarse para las funciones / comandos de difícil implementación por ejemplo FREAD, FWRITE, FLREAD.

[Añadido posterior]
Me temo que la mayoría de comandos NO llamarán a la instrucción SREAD ni SWRITE sinó que harán un JMP ó JSR a posiciones concretas de la ROM, con lo que el sistema de intercepción se complica por no decir que se convierte en imposible a menos que existan hooks en DOS para estas funciones!
Luis, trata de imaginar una forma para cualquier comando que NO sea SREAD ni SWRITE.
Trataré de echar una ojeada a un DOS desensamblado que tengo en alguna parte ...
[/Añadido posterior]

seguimos en contacto
saludos
pere

Avatar de Usuario
luiscoco
Mensajes: 2413
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 36 veces
Agradecimiento recibido: 57 veces
Contactar:

Re: Conectividad Dragon - PC

Mensajepor luiscoco » 15 May 2014 14:51

Yo pienso que como ya tienes casi todo hecho, una prueba real de SREAD puede ser rápida, y pruebas un dir a ver que tal

Avatar de Usuario
luiscoco
Mensajes: 2413
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 36 veces
Agradecimiento recibido: 57 veces
Contactar:

Re: Conectividad Dragon - PC

Mensajepor luiscoco » 15 May 2014 15:51

También se puede hacer una compresión de datos sencilla, por ejemplo para bytes iguales y así aumentar velocidad

Enviado desde mi HTC Desire C mediante Tapatalk

Avatar de Usuario
pser1
Mensajes: 2835
Registrado: 08 Dic 2012 18:34
Agradecido : 616 veces
Agradecimiento recibido: 744 veces

Re: Conectividad Dragon - PC

Mensajepor pser1 » 15 May 2014 16:33

Hola Luis,
he estado mirándome el DOS desensamblado:
DragonDos 1.0, Copyright (C) 1982, Dragon Data Ltd.
Disassembled 28/10/2004, P.Harvey-Smith.
Y al mismo tiempo con XRoar arrancado con DskDream desensamblando partes del DOS para concretar etiquetas (puntos desde donde se hacen llamadas)

Es un verdadero cirio, el Comando Leer sector (CmdSRead), punto entrada $DC79 no es llamado nunca dentro del DOS, es simplemente el punto de despacho de la orden SREAD con sus parámetros tanto si se lanza desde teclado como dentro de un programa Basic. Así que interceptarlo solamente serviría para desviar la orden directa SREAD. Ya puedo hacerlo en mi sistema.
Espero no pasarme con el ensamblador, voy a adjuntar aquí abajo el resumen de mis pesquisas al respecto:
Los nombres de las funciones son los empleados por P.Harvey-Smith
Para poner nombres a las etiquetas, de forma inteligente decidió simplemente añadir una L (de Label) por delante de la dirección hexadecimal, lo he mantenido.

Código: Seleccionar todo

Funciones definidas en DOS1.0
- DDosReadAbsSector ($D30A)
    Se le llama desde: $CA03 (DDosFRead)  y desde $D267 (DDosFindAndRead)
    Su código empieza así:
      LD30A   BSR      LD311
      LD30C   JSR      >DoReadAbsSector
      LD03F   BRA      LD2FF

- DDosWriteAbsSector ($D2FA)
    Se le llama desde: $CA08 (no está claro su uso) y desde $D2CF (no está claro su uso)
    Su código empieza así:
      LD2FA   BSR      LD311
      LD2FC   JSR      >DoWriteAbsSector
      LD2FF   LDX      <$EE
      LD301   TSTB
      LD302   RTS

Las dos Subrutinas con nombre está hechas así (y no es trivial)
- DoWriteAbsSector
      LC0FE   LDB      #$04
      LC101   EQU      *+1     * esto debe ser interpretado saltándose el CMPX, así:
              LDB     #$03
      LC100   CMPX     #$C603
      LC103   FCB      $8C    * esto es el opcode de CMPX lo cual produciria
              CMPX     #$C602
- DoReadAbsSector
      LC104   LDB      #$02
      LC106   PSHS     A
              LEAS     -2,S
              CLR      $0600
      LC10D   LDA      #$03
              STD      ,S
      LC111   ...                  * resto de código

La etiqueta LC101 (para escribir un sector), resulta ser llamada desde varios lugares:
- LC447,  LC450,  LC473,  LC7A3,  LDD0A  que no estan etiquetadas en el fichero desensamblado, por lo que no está claro que funciones representan

La etiqueta LC104 (para leer un sector), es llamada desde:
- LC76E (DDosSyncDir),   LDC2A (CmdBoot),   LDC93 (CmdSread)


Resumiendo la situación, NO hay hook ni nada parecido para interceptar el acceso a sectores, por lo que solamente me quedaría una opción:
Pasar a mapa1 (todo RAM) copiando las ROMS de BASIC y DOS a la parte alta y una vez hecho esto, parchear las entradas de estas funciones con un JSR a mi parte que manejará el puerto serie.
Con DoReadAbsSector parece factible ya que hay 3 bytes consecutivos que habría que desplazar a la nueva rutina para que si se decide NO hacer nada, se ejecuten allí. No problemo
Pero DoWriteAbsSector es cabroncete porque solo son dos bytes y hacen falta tres!
Además la parte inmediata es LC101 que se usa bastante y no se puede interceptar mas adelante porqué tropezamos con DoReadAbsSector.
Veréis que el código inmediato a DoWriteAbsSector es DoReadAbsSector así que, probablemente, en esta parte lo que se hace es cargar en el registro B el código de la operación a realizar.
Si interceptáramos únicamente LC10A que parece el menos malo de los puntos posibles, en función del valor de B se podría saber si la llamada atendida es una Lectura (B=2) o Escritura (B=3 ó 4) ... a verificar y probar!
Ya me dirás que opinas de este berenjenal -drinks
Mientras voy a seguir con mi proyecto tal como está y seguiremos dando vueltas a esta posibilidad que, a pesar de todo, parece interesante ya que resolvería funciones molestas de programar desde cero en Java, pero ésta era mi idea inicial.

saludos

Avatar de Usuario
pser1
Mensajes: 2835
Registrado: 08 Dic 2012 18:34
Agradecido : 616 veces
Agradecimiento recibido: 744 veces

Re: Conectividad Dragon - PC

Mensajepor pser1 » 15 May 2014 16:49

Hola Luis,
bastante peligroso el algoritmo de bytes repetidos, ya que habitualmente en un programa NO hay repeticiones seguidas, lo cual puede llegar a duplicar la longitud de datos a enviar.
Como cada byte está sólo una vez, hay que enviar el numero de repticiones y el byte (dos por cada uno).
El ejemplo típico es una pantalla gráfica en plan escaqueado, un pixel blanco y otro negro alternados, NUNCA hay repetición, es el peor de los casos, por supuesto.
El tema de compresión de datos lo he barajado, pero tras leer un artículo de Greg Zumwalt sobre el tema lo dejé de lado.
Este hombre es el inventor de los super packs de CoCo, estos que llevaban mas de 32k (en bancos de 8k) y además con los gráficos comprimidos
Adjunto el artículo que escribió este hombre en 1990

saludos
pere
Adjuntos
Breaking_The_32k pags 4-6.zip
segunda y última parte del artículo
(1.14 MiB) Descargado 63 veces
Breaking_The_32k pags 1-3.zip
primera parte del artículo
(1.33 MiB) Descargado 72 veces

Avatar de Usuario
luiscoco
Mensajes: 2413
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 36 veces
Agradecimiento recibido: 57 veces
Contactar:

Re: Conectividad Dragon - PC

Mensajepor luiscoco » 15 May 2014 17:25

Bueno se verá de último, a ver si tengo tiempo de meterme en el tema

Enviado desde mi HTC Desire C mediante Tapatalk

Avatar de Usuario
pser1
Mensajes: 2835
Registrado: 08 Dic 2012 18:34
Agradecido : 616 veces
Agradecimiento recibido: 744 veces

Re: Conectividad Dragon - PC

Mensajepor pser1 » 28 May 2014 22:15

Hola,
vamos despacito pero avanzando ...
A partir de ahora, ya no debo teclear las órdenes en el PC y esperar a que Dragón reciba los datos solicitados, por fin puedo teclear en Dragón y el programa residente en memoria que intercepta los comandos antes de pasarlos al BASIC, si es alguno de los aceptados lo envía al PC via puerto serie y espera resultado ...
Actualmente tanto LOAD como RUN funcionan correctamente, con lo cual el interés por el módulo SD pasa a ser cero. Es un placer cargar y/o ejecutar directamente un programa/juego desde una imagen VDK del PC -thumbup
Ahora me toca hacer que DIR, DRIVE y FREE envíen datos al Dragón, los dos primeros en plan texto puro mientras que la función va a ser más dura porqué hay que devolver la cantidad en formato exponencial (mantisa y exponente) de 5 bytes tal como lo definió Microsoft al hacer la ROM de Basic ... ya veremos como me las apaño.
Hasta ahora tomando la dirección de una variable Basic leo los cinco bytes y sé como calcular el valor representado, ya es un primer paso. Ahora hay que hacerlo al revés, descomponer un valor entero en los cinco bytes y POKEar los bytes apuntados por el puntero a la variable y ver si el Basic lo entiende correctamente, interesante!
Saludos
pere


Volver a “Dragon”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado