CP/M en Zx Dandanator! Mini

[Pachuquin]

Una pregunta tonta. ¿Y si se le pusiera una SRAM con una pila en vez de una Eeprom? Es mas cara y cambia la forma de grabación de los datos pero ¿mejoraría la velocidad?

[dandare]

Una pregunta tonta. ¿Y si se le pusiera una SRAM con una pila en vez de una Eeprom? Es mas cara y cambia la forma de grabación de los datos pero ¿mejoraría la velocidad?

Bueno, es que habría que cambiar casi todo el driver, pero sí, sería muchísimo más rápido, del orden de 5 veces, mínimo, en escritura. Igual en lectura más o menos.

[merlinkv]

Bueno, es que habría que cambiar casi todo el driver, pero sí, sería muchísimo más rápido, del orden de 5 veces, mínimo, en escritura. Igual en lectura más o menos.

¿Y merecería la pena? Yo creo que todo funciona bastante rápido ¿no? .... Bueno no se con el CP/M, pero para las ROMset's normales los tiempos de lectura/escritura están muy bien .....

A mí lo que me ha sonado muy bien era eso de ...... .DSK ....

[overCLK]

Gracias de nuevo por vuestros aportes y sugerencias. Está claro que a la hora de abordar un proyecto como este, surgen muchas encrucijadas en las que hay que tomar decisiones, y que puede que no todos hubiéramos ido por el mismo lado.

Para una cantidad menor de 512Kb de almacenamiento, yo creo que no tiene mucho sentido exponer diferentes particiones. Se puede disponer de cierta capacidad de organización haciendo uso de las áreas de usuario de CP/M, de las que tenemos, si no me equivoco, 15. Yo he hecho algunas pruebas poniendo por ejemplo, el disco de CP/M en el user 0, el wordstar en el user 1 y el Devpac en el user 2 y las aplicaciones parecen funcionar correctamente. Por poder, se puede hacer, pero complica tanto el driver, que ha de tomar la decisión de cuantas unidades desplegar (como hace el driver de otivax) y también el generador de los romsets, que tiene que tener en cuenta esta peculiaridad. Sopesando todo esto, me pareció mejor dejarlo todo en una sola unidad. La única desventaja que ofrece desde mi punto de vista tener una sola unidad, es que los bloques de datos tienen que ser de 2Kb (en los floppies de +3 suelen ser de 1Kb, aunque en los de DD de PCW son también de 2Kb, si no me equivoco).

Sobre el tema de añadir memorias u otros dispositivos de almacenamiento para mejorar la velocidad o aumentar la capacidad, entiendo que es una opción, pero yo creo que esto ya es más rápido que utilizar disquetes, que es lo que al fin y al cabo emula. Pensad que un disquete de +3 andaba por los 174Kb y al final tenías ahí tu aplicación y tus ficheros de datos y con eso te arreglabas. Pero si eres un forofo del CP/M, con esto y algo como el mod de Pachuquin para poder tener cartuchos individuales con diferentes aplicaciones, yo creo que vas sobrado.

Le veía cierta gracia a que esto se pudiera usar con el dispositivo original, aunque siempre es enriquecedor comentar modificaciones y mejoras, por supuesto.

[Pachuquin]

@overCLK no nos lo tengas en cuenta. Os habéis pegado una currada y el proyecto es genial.

Yo no he probado todavía el CP/M en disco y como dandare pedía que alguien midiera los tiempos en disco, pensé que era porque el dandanator era más lento que el disco,y y no al revés. Por eso sugerí cambiar la EEprom por una Sram. Pero que el proyecto tal y como está es una pasada. Lo que pasa es que nos encanta sugerir, aportar, dar vueltas de tuerca, sacar pegas, etc... pero eso no quita que valoremos el trabajo que habéis hecho.

[overCLK]

@overCLK no nos lo tengas en cuenta. Os habéis pegado una currada y el proyecto es genial.

Yo no he probado todavía el CP/M en disco y como dandare pedía que alguien midiera los tiempos en disco, pensé que era porque el dandanator era más lento que el disco,y y no al revés. Por eso sugerí cambiar la EEprom por una Sram. Pero que el proyecto tal y como está es una pasada. Lo que pasa es que nos encanta sugerir, aportar, dar vueltas de tuerca, sacar pegas, etc... pero eso no quita que valoremos el trabajo que habéis hecho.

Bueno, que no lo decía con ánimo de reproche. Siento si se ha entendido así.
Me parece muy bien que se sugieran cosas, y yo solo ofrecía mi punto de vista sobre ellas.

[Tromponauta]

Bueno, es que habría que cambiar casi todo el driver, pero sí, sería muchísimo más rápido, del orden de 5 veces, mínimo, en escritura. Igual en lectura más o menos.

¿Y merecería la pena? Yo creo que todo funciona bastante rápido ¿no? .... Bueno no se con el CP/M, pero para las ROMset's normales los tiempos de lectura/escritura están muy bien .....

A mí lo que me ha sonado muy bien era eso de ...... .DSK ....

¿Y lo de la SD-Ram no vendría bien para no hacer sufrir la Eprom? Según estoy leyendo las escrituras son continuas, no por cuestión de velocidad si no por alargar la vida de la Eprom.

[overCLK]

Bueno, para los impacientes, una pequeña preview del "mini generador".

Captura de pantalla 2017-03-14 a las 22.28.54.png

Se pueden arrastrar ficheros DSK directamente a la ventana y el programa extrae los ficheros que haya dentro y los añade a la lista. También se pueden extraer ficheros del Romset simplemente arrastrándolos al escritorio o con la opción del menú adecuada. En principio he probado con DSK de Spectrum y de Amstrad CPC y parece que funciona bien.

Además de poder modificar los atributos de los ficheros seleccionados con las opciones de la derecha, es posible filtrar por area de usuario con la caja de arriba a la izquierda. De este modo, si elegimos el User 1 por ejemplo, cualquier fichero (o ficheros de un DSK) que soltemos, se añadirán a ese area de usuario.

Hemos optado por no distribuir con el generador el fichero EMS de CP/M por el hecho de que no es libre. De todos modos, la operativa es tan simple como arrastrar un DSK de CP/M que tenga el fichero S10CPM3.EMS al programa, y luego extraer dicho fichero para añadirlo en la sección de preferencias:

Captura de pantalla 2017-03-14 a las 22.34.40.png

donde como veis también podréis personalizar la pantalla de arranque.

Falta hacer unos cambios finales para incluir el grabador por puerto kempston en la ROM y así facilitar el poder modificar fácilmente la flash sin necesidad de extraer la memoria y ya espero que pronto lo tendréis disponible.

[dandare]

@tromponauta
La eeprom que estamos utilizando tiene una durabilidad de más de 100.000 ciclos en cada bloque de 4k antes de mostrar ningún fallo o falta de fiabilidad. Esto es escribir cada 5 minutos el mismo sector durante un año, de manera ininterrumpida. La retención de datos, una vez grabados, es superior a 100 años.
Además, implementamos de forma completa la señalización de write-through y write-back del cp/m y gestionamos el sector en curso con marcas de clean/dirty, por lo que las escrituras se minimizan.

En resumen, si esto fuera para un uso intensivo o industrial, tendríamos que gestionar esos 100.000 ciclos, pero para el que le vamos a dar, creo que nos sobra bastante, aunque seamos muy aficionados al cp/m

Para mas info mira la nota TB702 de microchip, el fabricante, y de la memoria SST39SF040, la que usamos

[dandare]

...Falta hacer unos cambios finales para incluir el grabador por puerto kempston en la ROM y así facilitar el poder modificar fácilmente la flash sin necesidad de extraer la memoria y ya espero que pronto lo tendréis disponible.

Mañana lo dejamos listo

Enhorabuena, tiene una pinta excelente!