Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 05 Sep 2017 02:02

Último mensaje de la página anterior:

pser1 escribió:Luis, si buscas en el mismo Unravelled encontrarás esto:
RVEC7 RMB 3 $A426 $CA3B $CAE9 CLOSE ALL FILES
que indica que si NO hay cartucho de DOS, el 'hook' no haría nada y procedería con el puerto del casette
Pero si hay cartucho, entonces llama el CLOSE del que esté instalado ($CA3B o bien $CAE9 para DOS1.0 o DOS1.1.respectivamente)

No, si lo del HOOK yo lo se, lo que digo es que pone DEVNUM=0 que es pantalla y ya cerró los archivos?.
Te explico mi duda mejor y más detalladamente.
JSR RVEC7 HOOK INTO RAM (Esto está entendido)
LDA #-1 CASSETTE DEVICE NUMBER (Luego le pone cassette a juro, este abierto o no, que es por si quedó algo sin cerrar, no cierra serial, pantalla ni nada más)
0581 A42B 97 6F STA DEVNUM SET DEVICE NUMBER (aca lo pone en la variable de RAM y se queda tan ancho, claro al ponerle obligado el -1 de cassete, más abajo se tratara de cerrar si es output)

Luego el CLOSE FILE HANDLER
JSR RVEC8 HOOK INTO RAM (OTRO HOOK, OK)
LDA DEVNUM GET DEVICE NUMBER (carga el device number), si viene de CLOSE ALL ya tiene machacado -1 que es casette, si machaca (pone) cassette en la anterior, porque pregunta en esta zona, en vez de machacarlo igual que la anterior?
CLR DEVNUM SET TO SCREEN ( y, luego le pone 0 que es pantalla)
INCA *
BNE LA44B * BRANCH IF WAS NOT CASSETTE
LDA FILSTA GET FILE STATUS
CMPA #2 IS IT OUTPUT MODE ( y cierra el cassette si era OUTPUT)

PERO EL CLOSE ALL, lo machaca sin preguntar si es OUTPUT ni si está abierto

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 05 Sep 2017 06:28

Voy a tratar de ir compilando el fuente, agregando el cambio a RAM, no se si tu lo tienes más fácil, yo aun no se que compilador usaré.
Para empezar a hacer cosas, iré poniendo una lista de cosas por hacer, para irlas discutiendo. (BASIC desde la A Hasta la C)

Creo que No hay que cambiarle nada a estos
AUDIO ON/OFF
CLEAR [Espacio para caracteres] [, última pos]
CLOSE [puerto]:

Discutiremos estos: favor ver el link y opinar en este hilo
CLOAD/M
CLS
CONT
CSAVE/M nombre [, inicio, fin, arranque]:

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 15 Sep 2017 19:52

pser1 escribió:
luiscoco escribió:Si claro, tienes toda la razón, Lo que quiero es dejar tozos donde colocar las mejoras que hagamos, con un indice en el principal, por eso lo hago, posiblemente quite el código basic actual pero quedaría la discusión de comando.
Porque si se hace en un solo post, no se entiende, ya veras que después con el indice queda mas o menos bien.
Lo de empezar, estoy muy de acuerdo, cuando quieras empezamos, cual ensamblador te gusta, aunque también tengo uno, pero no me quiero liar.
Alguna preferencia?

Para editar textos en ensamblador, yo utilizo el TextPad en mi PC.
Una vez finalizada la edición lo compilo con ASM6809 de Ciaran Anscomb (Sixxie) o bien con LWASM de las LWTOOLS (William Astle)
cuando quiero controlar ciclos de reloj (optimizar velocidad de ejecución)
El binario que sale de cualquiera de los dos lo puedo cargar en XRoar mediante Control+L, así puedo grabarlo en disco,
si quiero guardarlo para mas adelante.
El tema es: ¿A que nos dedicamos? Al Basic de CoCo o al de Dragón? Porqué hacer uno único que funcione en los dos, dudo que
seamos capaces sin dedicar SEMANAS al análisis detallado de las implicaciones que comporta: De entrada por poca cosa que toques,
los D.O.S. respectivos dejarán de funcionar ya que hacen multitud de llamadas a SU Basic y las 'entradas' que llevan a cabo cada
comando o palabra reservada son diferentes y están en distinta posición de memoria -banghead
saludos
pere

Pues, veamos, el basic de la DRAGON, y sus DOSs son superiores casi siempre, si no fuera por el Super extended te diría que casi matábamos al de la coco, pero vamos con cuidado.

Las mejoras que hasta ahora he planeado, casi todas aun en la cabeza, y nada concreto, hay que ir las bajando de nivel, y podemos empezar con cualquiera, seguro que todas nos darán dolor de cabeza, jeje.

Si empezamos por lo difícil, crearle notaciones de integer, long ... etc., nos podemos demorar mucho, no estamos aun tan duchos, y seria muy largo ya cuando estemos mas familiarizados con, como funciona el basic, nos metemos.

Pienso que apaño pequeños mientras nos acostumbramos sera mejor.

El problema que tengo es que no conozco la DRAGON y menos su basic por dentro, entonces si mejoramos algo de la coco y no me avisas que la DRAGON o algunos de los 7 DOS que tiene lo hace mejor, pues me quedare en el aire o tendré que re-programar y eso no se quiere.

Fíjate lo mal que estoy en DRAGON, que me quede alucinado simplemente con el DISKINIT que yo sabia que formatea 80 pistas y 2 lados pero no recordaba el mensaje de pantalla, que me gustaria que lo tuviese la COCO, y la curiosidad de verificar hacia atrás, un acierto si es que no tarda mas que hacia delante, vanos un mundo por delante de la coco, no se diga del DIR, pero ya veremos eso después.

Creo que te puedo proponer ir desde arriba del basic bajando y mejorando, pero necesito comparar mucho con la dragon, quiero ser muy cuidadoso he ir manteniendo lo mas posible la compatibidad.

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 15 Sep 2017 20:15

De entrada te propondría lo siguiente:
Después de las inicializaciones y Warn/Cool Start, comienza con:
RUTINA CONSOLE IN ($A176 - $A1C0 )
RUTINA DE LECTURA DE TECLADO (KEYIN)($A1C1-$A244)
CONSOLE OUT

La lectura de la Dragon esta muy bien, (aun sin interrupciones), pero no puedes pedir nada que tarde sin tener que esperar, y ya que debería tener algunas cosas en paralelo pues podrían irse pensando. Se que no quieres interrupciones, pero si imprimes en papel (que ya no se usa) o usas sonido, hay que esperar que termine, imposible hacer juegos así.

Yo pienso que para el sonido, es importante que tenga algún mecanismo de interrupción, se que ralentiza, suena raro. Se que en los juegos de assembler lo que se usa es sincronizarlo con las acciones nada mas. Pero si la meta es tener un basic en el que cualquiera se haga un jueguito sencillo y con sonido, pues no veo otra que hacer una imitación de sonido por su propia cuenta y que el basic continué. También se podría parametrizar, o sea, sacar el sonido en paralelo o esperar que termine.

Así que mientras no sea una piedra de tranca, yo lo pondría, o sea, interrupciones para teclado (solo una parte base, luego te explico), para spooler, para sonidos, y ya veremos que hacemos con el DOS, tal vez detenga los interrupt cuando sea necesario que es lo que hace ahora de todas formas.

Pero antes de meternos tan adentro, una pregunta sencilla, te gustaría un cursor COCO en el DRAGON?, así se distinguiría fácilmente este BASIC que trae, o te parece que se ve muy de juegos o de niños?.

Tampoco es que quiera hacer un sistema operativo multitasking que ya para eso esta el OS9/NitrOS-9, pero si lo básico, por ahora teclado, sonido, serial, paralelo, y algo del disco, actualmente se chequea por teclas y por BREAK entre cada comando, pero si el comando tarda mucho se podría chequear varias veces durante el comando y tomar acción o guardar las teclas presionadas para después usarlas.

La idea es que no pierdas teclas, como decías tu antes, si sacas un DIR y te pide teclas por cada pagina, entonces de que te serviría memorizar lo que escribes (decías tu), pero yo pienso que si quieres ver la pagina 4 del DIR es mejor darle 3 veces a la barra (o cualquier tecla) y no estar esperando que muestre cada pagina para después presionar la barra, o como me pasa a mi mucho, que sencillamente pierde el comando por no haber terminado la acción.

Si quieres inicialmente solo hacemos lecturas en medio de algún comando largo, como en el DIR, se podría hacer una lectura y si no es BREAK memorizarlo para después usarlo, digamos que por cada linea impresa. Y si no, pues por interrupción digamos 5 veces por segundo o algo así.

Yendo un poco mas lejos, si presionas 1234 ala vez, en COCO pone 1234 en DRAGON 32 NO, solo pone 1, ya en 64 si lo hace como en la COCO, que tampoco es perfecto ya que si presionas a la vez QWER Y GHJK lo que escribe es @ASDF, JEJE.

Pienso que si nos guiamos un poco por como lo hace la PC seria bueno, La PC al menos en MSDOS almacena teclas y si se llena el buffer sonaba un pitido, en la coco con las teclas tipo chicle, también seria bueno algún sonido por tecla, ya que no se siente cuando se presiona correctamente la tecla.

LA MATRIZ se leería completa, con las 4 teclas de función, que bien podemos usar, aunque con alternativa, para los que no las tienen.
Unas teclas que echaremos en falta siempre son CTRL, ALT, DELETE, ESC, y las teclas de función. En el teclado especial de mi COCO1, tengo todas las 4 de función y viene con un programa que activa comandos de basic por cada tecla estilo ZX82, y tenia un definidor de teclas a gusto del usuario, también usa la FLECHA ABAJO creo, como tecla de función o CONTROL.

Para ESCAPE podemos usar BREAK. Yo colocaría la tecla de CLEAR como control, cuando no aya otra mejor, el que tenga las teclas de función que las use, incluso cualquiera se podría usar o definir.

Para guardar estas configuraciones planeo poderlas guardar en un disco y habrá algún boot, ya veremos.

Por ahora seria como un bios pero no guardaría nada, jeje, LOS DE HARDWARE vayan pensando en una Flash o memoria con pila, jajaja

Bueno pasando del tema.

INTERNAMENTE
Lectura en 2 partes, al llamar a la primera (por interrupción o directamente aun no lo definimos), escanea filas y columnas, y si no hay nada sale, en este momento curiosamente hay que quitar los Joysticks del medio y otras cosas, ya bien se podrían leer de una vez, pero luego lo vemos.

Una vez encontrada la tecla o teclas, ya que pueden ser varias, estas se almacenan en el buffer de teclado y se sale, no mas.

La otra función buscaría solamente en el buffer y retorna de a UNA, las teclas del buffer, tiene que haber un semáforo, para no choca entre las dos funciones, una que rellena el buffer y otra que lo vacía.

* Cada tecla tiene un scancode, directamente la multiplicación de filas por columnas o algo así. Creo que el cero no se debería usar. El scancode no se si sea necesario, pero para juegos a veces es necesario revisar varias teclas a la vez y también ver si una tecla esta arriba o abajo

* Pienso que se pueden devolver los 8 bytes que definen las teclas presionadas en paralelo aunque ya están en los bytes bajos, pero creo que el basic no podría analizarlo rápido

* Si hablamos de pulsaciones de teclas y su des-pulsación podemos sumar 128 a la pulsación, y vamos rellenando el buffer, no se si también con las repeticiones de teclas.

* Cuando presionamos Break, este tiene preferencias y se ubica al principio de la cola, pudiendo así detener ciertas acciones.

* Si el buffer es para caracteres convertidos ASCII pues vale también lo del 128 o enviar algún carácter delante para saber que se des-presiono una tecla. Pero faltaría saber si en determinado momento esta presionada una tecla o no, aparte del buffer.


ESTOY UN POCO LIADO, DEJAME REPASAR Y ORDENAR TODO ESTO

Matriz de teclado DRAGON.png
Matriz de teclado DRAGON
Matriz de teclado DRAGON.png (13.64 KiB) Visto 119 veces

Matriz de teclado COCO.png
Matriz de teclado COCO
Matriz de teclado COCO.png (64.04 KiB) Visto 119 veces

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 15 Sep 2017 21:57

pser1 escribió:Existen rutinas ya hechas, en realidad en el Dragon 64 cuando pulsas EXEC y el cursor pasa a color azul, acaba de poner en marcha el sistema de
autorepetición controlado por una variable de la parte baja ($11f = retardo para repetición de teclado).
En un Dragón 32 puedes entrar este cortísimo programa Basic o entrarlo a mano:

Código: Seleccionar todo

100 POKE&HFF03,(PEEK(&HFF03)AND&HFE):POKE&H10D,&HBF:POKE&H10E,&H20:POKE&HFF03,(PEEK(&HFF03)OR1)

Lo que hacen estos pokes es:
El primero desactiva el IRQ y el último lo reactiva ...
Los otros dos modifican el hook para IRQ, lo derivan hacia la rutina en $BF20 que, en teoría, es utilizada por el BASIC modo 64 para controlar
la repetición de teclado, pero existe incluso en los D32! Puedes probarlo, funciona perfectamente -thumbup
Hay muchos secretos escondidos entre el Basic y el Hardware -507
saludos
pere

JAJA, facil, facil, no se en que me equivoque, el primero lo hice sin el 100, y me pinto un carácter gráfico, el segundo lo hice como linea de basic y al rodar lo me tranco el emulador, jajaja, nada que prefiero KEYREPEAT, jajaja.

Dragon teclado.png
Dragon teclado.png (15.34 KiB) Visto 123 veces

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor pser1 » 16 Sep 2017 00:34

Luis,
En UNA sola línea de Basic se cuelan DOS diferencias brutales ... mal lo llevamos, amigo!
Aquí va la imagen de lo que si produce repetición de teclado
saludos
pere
RepeticionTecladoDragon.jpg
RepeticionTecladoDragon.jpg (53.46 KiB) Visto 111 veces

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 16 Sep 2017 01:20

Jajaja, Si me lo imagine, jeje, era broma, pero sigo prefiriendo keyrepeat
Lo hice muy rápido, iba saliendo, jeje, hasta duplique una linea, ajaja, no pegue ni una, jajajaja

Porfa lee el post anterior a estos para ir tomando acciones

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 16 Sep 2017 14:26

SCAN DE TECLADO COCO/DRAGON

No se si algún programa usa los 8 bytes en variables bajas del SCAN de teclado DRAGON el cual esta en un orden diferente al del COCO

Ya que el orden del juego de caracteres es idéntico entre COCO y DRAGON, el orden de la matriz debería estar igual, pudiendo hacer simplemente una rotación de estos 8 bytes ya quedaría igual que en COCO.

Otro método seria dejar estos 8 bytes quietos y hacer el cambio a la salida ASCII.

Pero en este basic se podrán hacer cosas como saber que tecla esta pisada y cuando se soltó y lo lógico seria tener un código de cada letra parecido al ASCII y si es posible idéntico entre COCO y DRAGON.

Por eso propongo hacer un cambio para DRAGON al finalizar la rutina de KEY rotar los 8 bytes de teclado para dejarlos idénticos al COCO, el sistema contará con alguna manera de desactivar esto.

Pasaremos el PA2 al PA5 al PA0 y el PA0 y PA1 al PA4 y PA5, Pasando de FOTO 1 A FOTO 2
Matriz de teclado DRAGON.png
Matriz de teclado DRAGON.png (13.64 KiB) Visto 96 veces

Matriz de teclado DRAGON Modificado.png
Matriz de teclado DRAGON Modificado.png (19.59 KiB) Visto 96 veces


Juego de caracteres COCO-DRAGON.png
Juego de caracteres COCO-DRAGON.png (16.1 KiB) Visto 97 veces

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 16 Sep 2017 15:10

DETECCIÓN DE TECLAS
En el DRAGON si mantenemos la tecla "A" pisada y marcamos la "B" no aparece nada en pantalla, solo usando otra tecla de otra fila si la toma, como la "H", esto solo para en DRAGON 32, en 64 funciona mejor y si detecta la "A" y la posterior "B", ademas repite la "A" y si las dos teclas están pisadas repite las dos pero mas despacio.

En cambio en la coco ocurre algo parecido a la 64, y procesa correctamente todas las teclas, esto me indica que la programación es mas precisa en la 64 y en la COCO, también he notado que la dragon 32 pierde algunas teclas si se tipea rápido.

Solo un detalle mas, la DRAGON 64 escanea las filas en orden inverso(al parecer) y las columnas en orden correcto, esto es columnas de 7 a 0 pero las filas las hace también de 7 a 0 en lugar de 0 a 7. entonces si pisas "A" y "H" aparecen "HA" siempre y no "AH" que seria lógico, como cuando pisas "AB" que aparece siempre "AB" y aunque pises "BA" aun así saldrá "AB" al menos en las repeticiones.

Conclusión hay que escanear las filas en el orden 0 a 6. estos métodos no son perfectos, pero seria muy complejo tal vez hacer todo como debería ser, o sea, que no pierda ninguna tela aunque las pises a la vez, que repita las teclas según su tiempo individual abajo, y que las repita en el mismo orden en que se bajaron. pero hasta ahora gana el código de la DRAGON a ver si aguanta alguna mejora.

Aunque creo que tengo un error ya que la "AH" están en diferentes columnas, la "H" esta en la columna 0 y la "A" en la 1 creo que por eso pinta repeticiones de "HA" y no "AH" y no por las filas, pero aun encuentro otros efectos anormales, si las teclas están en la misma columna, solo repite la primera.

Para mas detalle ver pag. 203-204 del Inside of DRAGON. en las que afirman que esto no es suficiente para juegos.

Estudiare el código de la DRAGON para ver que encuentro, porque lo que si me interesa de el es lo de la repetición de teclas, a ver como lo resolvieron, ya que cada tecla debería tener su propio tiempo antes de repetir, si estas fueron pisadas en diferentes momentos, pero tal vez solo usan un tiempo para todas las teclas y repetirá según la mas antigua tecla pisada.

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 16 Sep 2017 16:43

pser1 escribió:Dragón no tiene unravelled series. Existe un libro en alemán llamado "Das Dragon Lexikon" que contiene la ROM de Basic desensamblada
en plan unravelled, pero increíblemente NO fué traducido ni al inglés! Referencia:
Jörn W. Janneck, Till Mossakowski: Das Dragon 32/64 Lexikon. Röckrath Mikrocomputer, Aachen 1984, (ISBN 3-925074-05-8).

No encontre el libro en PDF, que otra opción hay?
Hago un unravelled para dragon?
En Español y en ingles?

--------------------------------------
Interesante pagina:
Create your own Version of Microsoft BASIC for 6502

Avatar de Usuario
pser1
Mensajes: 2013
Registrado: 08 Dic 2012 18:34
Agradecido : 198 veces
Agradecimiento recibido: 181 veces

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor pser1 » 16 Sep 2017 17:15

luiscoco escribió:
pser1 escribió:Dragón no tiene unravelled series. Existe un libro en alemán llamado "Das Dragon Lexikon" que contiene la ROM de Basic desensamblada
en plan unravelled, pero increíblemente NO fué traducido ni al inglés! Referencia:
Jörn W. Janneck, Till Mossakowski: Das Dragon 32/64 Lexikon. Röckrath Mikrocomputer, Aachen 1984, (ISBN 3-925074-05-8).

No encontre el libro en PDF, que otra opción hay?
Hago un unravelled para dragon?
En Español y en ingles?

Yo alucino contigo, Luis.
NADIE lo ha intentado en 35 años y ahora pretendes hacerlo tu y en dos idiomas!
¿Tu vas a comentar linea a linea el contenido de la ROM del Basic?
Parece que ya no te acuerdas de las dificultades en conseguir un fuente que compilara generando el mismo ejecutable
para el Hobbit en Z-80. Y este Basic ocupa 16K completos.
Cuando hayas 'separado' los datos del código ... y hay unas cuantas tablas en la ROM, entonces empezarás el trabajo de
comentar línea a línea o por lo menos entender que hace cada bloque ... ya me irás contando xD
saludos
pere

Pd Me temo que en Dragón nos hemos acostumbrado a trabajar directamente en ensamblador y para eso no hace falta
saber que hace el intérprete de Basic, salvo unas cuantas rutinas que se publicaron en su momento en las revistas especializadas
Ni siquiera el DOS existe desensamblado y explicado (solo 8k)

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 16 Sep 2017 19:00

Si me atrevo, primero porque debe ser muy parecido al COCO y tal vez hasta copie trozos
Segundo rengo un ayudante des-ensamblador, no terminado que es interactivo, marca zonas de data, y desensambla otra vez en vivo, tiene variables para ir indicando cosas, te ayuda a nombrar rutinas, también identifica las sub-rutinas y te las separa visualmente y te hace una tabla

Una pregunta porque la DRAGON tiene 2 ROM de 16, el XROAR tiene d64ROM1.ROM y d64ROM2.ROM los dos de 16k, al parecer uno es para un D64 en modo 32 y el otro es D64 Puro, pero la pregunta es, físicamente la D64 tiene 2 ROMS de 16k?
Y la Tano otros 2
La D32 si tiene uno solo de 16k

jltursan
Mensajes: 1876
Registrado: 20 Sep 2011 13:59
Agradecido : 47 veces
Agradecimiento recibido: 141 veces

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor jltursan » 16 Sep 2017 19:39

Pues si no me equivoco y tal como sugieres, el Dragon 64 tiene físicamente 2x16KB porque uno contiene la ROM con el BASIC ejecutado en el modo "Dragon 32", cuando conmuta a modo 64KB, el contenido de la segunda ROM se copia a RAM y se ejecuta el intérprete de BASIC "Dragon 64"

EL Dragon 32 tiene dos integrados de ROM; pero simplemente porque son 2x8KB, para dar el mismo total de 16KB que su hermano mayor en modo 32.

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: Proyecto Basic CoCo/Dragon/DP400 (Discusiones)

Mensajepor luiscoco » 16 Sep 2017 21:02

jltursan escribió:Pues si no me equivoco y tal como sugieres, el Dragon 64 tiene físicamente 2x16KB porque uno contiene la ROM con el BASIC ejecutado en el modo "Dragon 32", cuando conmuta a modo 64KB, el contenido de la segunda ROM se copia a RAM y se ejecuta el intérprete de BASIC "Dragon 64"

EL Dragon 32 tiene dos integrados de ROM; pero simplemente porque son 2x8KB, para dar el mismo total de 16KB que su hermano mayor en modo 32.

Pues muchas gracias, aun no he querido abrir mi dragon TANO que esta super nueva, jeje


Volver a “Tandy CoCo”

¿Quién está conectado?

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