ORIC DSK Manager por overCLK.

[ron]

Último mensaje de la página anterior:

Confirmo que los mismos DSK convertidos a HFE para HxC tampoco funcionan. Tienen el mismo efecto que con el cumulus.

Se me ocurre usar una imagen ya creada, que sepa que arranca y ver si inyectando funciona. Del mismo modo que con el Oricutron copiando de una unidad DSK a otra pero con media diferente. En fin que la cuestión era romper la jaula, ahora hay que ir mirando cosas y poco a poco esto llegará a chutar de miedo.

Saludos

[retrolab]

Vaya chulada de programa. Será muy útil para mi atmos que ultimamente estaba echando polvo...

[overCLK]

Confirmo que los mismos DSK convertidos a HFE para HxC tampoco funcionan. Tienen el mismo efecto que con el cumulus.

Se me ocurre usar una imagen ya creada, que sepa que arranca y ver si inyectando funciona. Del mismo modo que con el Oricutron copiando de una unidad DSK a otra pero con media diferente. En fin que la cuestión era romper la jaula, ahora hay que ir mirando cosas y poco a poco esto llegará a chutar de miedo.

Saludos

Vale, ¿tienes algún DSK con ese mismo formato 2/40/17 que sí te funcione en el cumulus y me puedas pasar? Analizándolo creo que podré ver las diferencias.

[Chema]

Recordar que tap2dsk solo crea discos de una cara.

[ron]

Creo que cualquiera de los Oric_OK funcionan en el cumulus.

[overCLK]

Versión 0.2:
Mejorada la gestión de DSK, ampliando la lista de los que se pueden cargar sin error. Todavía quedan por analizar bastantes casos de fallo, por elementos inesperados en la estructura del directorio.
Corregido un bug muy feo en la reserva de sectores que hacía que se corrompiese el directorio cuando los ficheros excedían cierta longitud.


https://github.com/teiram/oric-dsk-mana ... s/tag/v0.2

[luiscoco]

Hola, probe el mio (El Plug-in para total commander) pero solo ve y saca los archivos aun no los mete en el DSK
En esta imagen se ve el juego de Chema, en .DSK, con la vista de los archivos internos, se entra en ella como si fuera un .zip, y luego se pueden sacar al directorio de PC, creo que olvide hacer el retorno de datos al .DSK

[ron]

Versión 0.2:
Mejorada la gestión de DSK, ampliando la lista de los que se pueden cargar sin error. Todavía quedan por analizar bastantes casos de fallo, por elementos inesperados en la estructura del directorio.
Corregido un bug muy feo en la reserva de sectores que hacía que se corrompiese el directorio cuando los ficheros excedían cierta longitud.


https://github.com/teiram/oric-dsk-mana ... s/tag/v0.2

Ya estoy probando, os digo como ha ido en cuanto le pegue un repaso.

overCLK, thx again !!!

[minter]

Que velocidad! Nueva versión!
Leyendo las pruebas anteriores de ron, conceptos, emplear el PC como transmisión serie, etc...
Ver este programa tan sencillo y a la vez tan potente, deben de estar los usuarios de Oric aun anonadados!

[luiscoco]

Felicidades overCLK, Muy buen trabajo.
No se si podre terminar el mio, porque no encuentro copia de los fuentes

[ron]

Hola !

Tenemos alguna noticia nueva. overCLK me ha comentado que configurando el Manager a 1 Cara, 21 Pistas, 17 sectores ; el DSK generado se puede convertir a HFE y es funcional en las HxC/Gotek.

1-21-17_oric.png (9.21 KiB) Visto 419 veces

Lo que voy a hacer es generar un DSK y probar tanto con controladora como con Cumulus. El punto era que los DSK que estábamos generando dejaban torrao el Oric al arrancar y overCLK ha conseguido montar un DSK, hacer boot y ejecutar hasta el Xenon.

Igual esto acaba en retrocrypta, ya estoy picado... jeejejej

Lo que está haciendo overCLK es ahora mirar con una imagen de disco DD que tire bien en HFE y buscarle las cosquillas. Si ha dado con los 21 tracks en simple cara a ver que nos cuenta...


Comentarios y pruebas bienvenidas.

[ron]

Confirmo que en Cumulus los DSK a 1 cara, 21 pistas, 17 sectores son totalmente funcionales.

fonacumulus.jpg (35.56 KiB) Visto 408 veces

pantllacafona.jpg (69.7 KiB) Visto 408 veces

[ron]

Del mismo modo que el HFE usado con las HxC funciona OK. De hecho he pasado programas en BASIC y TAPs y funcionan OK.
Es ya todo un avance. Entiendo que si monto en el emulador una imagen que funciona como la de Battlestar y le añado desde SEDORIC ficheros estos al menos deberian verse refejados en el DSK que el emulador toque, probaré con Oricutron y con Euphoric y de paso probaré en real con el Cumulus ya que puedo tener hasta 4 DSK diferentes en uso de forma simultanea.

[Chema]

No me entero muy bien... Estoy este finde un poco desconectado y, por lo que veo, espeso. Me pareció que imágenes de más de 21 pistas funcionaban bien. ¿Estáis diciendo que imágenes que no funcionan, si las grabáis a 21 pistas, sí que lo hacen? Porque durante la retrocripta yo hice una imagen con el Xenon1 e iba en el emulador al menos... Eso sí haciendo QUIT primero.

Si es eso, es curioso. Parece una pista importante para buscar el posible fallo, porque tap2dsk genera discos de hasta 80 pistas....

[overCLK]

No me entero muy bien... Estoy este finde un poco desconectado y, por lo que veo, espeso. Me pareció que imágenes de más de 21 pistas funcionaban bien. ¿Estáis diciendo que imágenes que no funcionan, si las grabáis a 21 pistas, sí que lo hacen? Porque durante la retrocripta yo hice una imagen con el Xenon1 e iba en el emulador al menos... Eso sí haciendo QUIT primero.

Si es eso, es curioso. Parece una pista importante para buscar el posible fallo, porque tap2dsk genera discos de hasta 80 pistas....

En emulador parecen funcionar todas bien. Nos estábamos centrando en hacer que funcionasen sobre controladora física. Ahí las de simple cara (o al menos las de 21 pistas) funcionan pero hay algo que no le gusta cuando el disco es de doble cara (aunque todavía no estoy seguro de que sea exactamente por esto). He visto que algunas imágenes DSK de doble cara que sí funcionan (ya existentes, no creadas con la aplicación) , tienen un encoding MFM un poco diferente del que generaría oldmfm: una secuencia {C2, C2, C2, FC} en la cabecera de cada pista y el GAP2 con 0x4E en lugar de 0x22 como lo hace oldmfm. Cambiando estos detalles en las imágenes generadas siguen sin funcionar, así que probablemente el problema está en otro sitio, o en varios sitios a la vez.

A mi me da la impresión de que tiene que ver con la codificación a bajo nivel de la pista (gaps, valores,crc,...) pero comparando con una imagen viable todavía no he encontrado qué es lo que marca la diferencia. Por si a alguien le puede sonar a algo:

- Arrancando con una imagen defectuosa (pasándola a HFE), sale el mensaje de copyright de Sedoric y se tuesta.
- Arrancando con otra imagen válida y luego cambiando el disco por el defectuoso, haciendo un DIR, sale este mensaje de error:

Código: Seleccionar todo

TRACK: 14 SECTOR: 01  READ FAULT 10
?DISK I/O ERROR


La pista 14 supongo que está en hexadecimal y se refiere a la pista 20, sector 1 donde se guarda el bitmap. Por alguna razón no le gusta como está codificada, o el CRC o lo que sea.

Tanto sobre Oricutron como Euphoric, las imágenes de doble cara funcionan correctamente, o al menos arrancan el sistema y permiten listar los ficheros y ejecutarlos. La información sobre caras, pistas y sectores en un DIR también parece consistente.

Soy optimista porque teniendo imágenes de doble cara que sí funcionan, supongo que es cosa de ir aislando las diferencias con las imágenes generadas por la herramienta y ver por qué se producen. Ya iré informando.


EDIT: De estas cosas que se encuentran de casualidad: Resulta que si en la imagen de doble cara haces dir varias veces, acaba sacando el directorio. Esto creo que puede significar que el problema está en la codificación a bajo nivel, y debe haber algo mal con los gaps, valores de relleno o similar. Si lo lee al menos una vez es que el CRC debe estar bien y la información es además consistente. Es como si no consiguiera engancharse bien al flujo de datos. Intentar ejecutar luego algún archivo de la imagen lleva a nuevos errores I/O del mismo tipo. Así que toca comparar imágenes DSK y ver que diferencias quedan.

battlestar.jpg (55.78 KiB) Visto 263 veces

[Chema]

Puf... Esto suena complicado. Te cuento un poco lo que yo recuerdo, por si te diera alguna pista. Lo primero, el Gap2 es 4e, no 22. No sé de dónde apareció ese 22, pero no debe ser así. Dicho esto, da igual, porque el emulador y las herramientas que tuestan los discos físicos, pasan de todo eso y buscan directamente los datos o los registros de identificación (las secuencias a1 a1 a1 si no recuerdo mal). Al grabar esos datos, la propia controladora pone el formato correcto, y el CRC lo vuelve a calcular, así que pasó desapercibido.

De hecho los emuladores y el cumulus, tampoco comprueban los CRCs

El formato del disco es http://info-coach.fr/atari/software/_fd ... bm-fmt.gif

Bueno, lo que digo es que si no va con él cumulus (no sé cómo es el formato del HxC pero apuesto que le ocurre igual) no creo que sea un problema de ahí.

Si tu código viene de tap2dsk hay algunas cosas que tener en cuenta. Nunca soportó más de una cara, no sé por qué) pero no me parece que sea difícil. De todas formas tenlo en cuenta.

Otra cosa, es que los discos generados con tap2dsk daban problemas cuando introduces o borras archivos. A veces, nadie dio con el problema, pero puede ser que lo estés experimentando. Si hay algo mal en los datos del bitmap o del propio Sedoric, cualquier cosa puede pasar. Pero es muy raro que en el emulador funcione.

No sé qué más aportar. Yo he creado discos de más de 21 pistas (eso sí que me mosquea, que funcione bien para 21...) como, creo, Space1999 y 1337 y ambos funcionan bien. Tap2dsk y writedsk en ambos casos.

[ron]

Bueno, ya que lo cuente el propio overCLK, solo un adelanto.

btl01cumrw.jpg (31.91 KiB) Visto 771 veces

btl02cumrw.jpg (50.32 KiB) Visto 771 veces

Ya lo tiene, esto es UNA PASADA !!!! ya solo nos toca esperar a la 0.3 !!!! nivelazo !!!