cartucho ROM de 512Kb

[wilco2009]

Quería saber vuestra opinión sobre si sería útil lo siguiente.

En ocasiones anteriores se ha planteado que tener 512Kb RAM no es todo lo útil que podría parecer ya que sólo disponemos de 32Kb para el programa principal, debiendo utilizar los 16Kb superiores para almacenamiento de sprites, mapas etc.

¿Veríais útil la existencia de un cartucho ROM de 512Kb que paginara los primeros 16Kb de ROM a nuestra voluntad?

Para cambiar de página se haría con un out pasando como parámetro un número de página entre 0 y 31.

[mcleod_ideafix]

Ambas soluciones tienen sus ventajas e inconvenientes:

Cartucho ROM de 512KB
Entiendo que es eso, un cartucho ROM con el patillaje estándar disponible para cartuchos ROM del Interface 2, y que sería compatible no sólo con el Interface 2, sino también con el Interface RAM Turbo, el SPECTRA, o incluso con un Interface 2 "casero" para aceptar unicamente el cartucho y poco más. Lo digo porque esto sería incompatible con el método de cambio de banco que propones, usando un "OUT". En un cartucho sólo está la señal MREQ, y ni siquiera están RD y WR.

Bueno, pues suponiendo eso, las ventajas que le veo a esto son:
- Funciona en cualquier Spectrum, suponiendo claro está que se tenga el Interface correspondiente, que por otra parte es de las cosas más sencillas de fabricar.
- El código y datos están disponible instantáneamente; no hay que cargar nada de cinta, disco o memoria flash.

- Inconvenientes: pues que al ser memoria no escribible, no se puede emplear para todo, si no sólo para albergar datos que no tengan que cambiar. Esto, pues puede ser un inconveniente real, o no. Todo depende del tipo de juego/aplicación que pongas en su interior. Probablemente para un juego basado en mapas, o una aventura conversacional, agradezcan grandes cantidades de memoria con datos estáticos, y no necesiten excesiva RAM para variables, bufferes y cosas así.
Otro inconveniente radica en el método de selección de banco, que al no poder ser un OUT, tiene que ser por fuerza un acceso a memoria. Esto significa que no todos los 16KB estarán disponibles para el usuario, sino que algunas direcciones (quizás la última) tendrá que reservarse como dirección fantasma, de forma que cuando se acceda a ella, el cartucho lea el bus de datos y lo interprete como un número de banco al que hay que cambiar.

Memoria RAM 512KB
Pues al contrario que lo anterior. La ventaja es que puede usarse para albergar no solamente datos estáticos, sino también variables y bufferes. Útil si el juego se aprovecha de cosas como el uso de sprites compilados, que necesitan mucha RAM.
Inconvenientes: que en este caso sí que se necesita una interface propietaria, como la que estás haciendo. Esto sin embargo trae una pequeña ventaja, y es que aquí sí podrás usar un OUT para cambiar de página.
Otro inconveniente es que si esta RAM se va a usar sobre todo para albergar datos estáticos, esos datos tienen que venir de algún sitio, y eso supone cargarlos desde audio, disco, o memoria flash. Si tu interface soporta alguna de las dos últimas opciones, esto no es problema, pero si no, y hay que confiar en la carga por audio, aunque sea turbo, será un peñazo de aquí te espero el cargar toda esa información.

Con todo, el principal inconveniente que le veo a cualquiera de las dos opciones es: ¿hay software actualmente que necesite 512KB de RAM o ROM? Quizás para una RAM de 512KB haya alguna demo técnica hecha para Pentagon o Scorpion, pero juegos reales no conozco. Y en caso de que las hubiera, convertirlas para que se ejecuten desde un cartucho ROM de 512KB me parece poco menos que una tarea imposible.

En algún sitio leí que tener grandes cantidades de RAM o ROM no es la solución para juegos grandes. Que con 128KB de RAM era más que suficiente, y que la solución iba por disponer de un sistema de carga basado en memoria flash (SD, CF, etc), y olvidarse de la ROM excepto para las llamadas al sistema operativo para cargar cosas (esto es, usando algo como +3DOS o ESX-DOS)

[wilco2009]

La idea de hacerlo como cartucho ROM de IF2 es atractiva, pero el tema no iba por ahí. El tema iba porque se me ha ocurrido que, sin ningún tipo de cambio hardware, podría utilizarse mi interface como un inmenso cartucho ROM de 512Kb. De tal manera que tendrías ambas cosas, 512Kb de RAM y también 512Kb de ROM.

Evidentemente no se trata de convertir el software existente, la pregunta iba más bien, por ver si podía resultar atractivo tener cartuchos ROM, específicos para mi hardware, de 512Kb a la hora de programar un juego.

Otras aplicaciones de tener una ROM de 512Kb tambien se me han ocurrido, como por ejemplo ampliar el juego de comandos del +3, almacenando utilidades en las distintas páginas de la ROM, pero esto ya requiere modificar el SO y es algo más complicado.
Sería algo parecido a los comandos RSX de los CPC.
Cuando antepusieramos un carácter determinado al comando, por ejemplo una @, la rutina de error copiara el comando a RAM y cambiara a la pagina X, donde tendríamos una tabla Comando/página de rom/dirección.
Ya digo que esto es bastante más complicado a nivel de programación.

[zup]

Personalmente, yo veo más atractiva la idea de usar el disco (SD o CF) como almacenamiento. Es más accesible a la hora de meterle cosas y además ya tienes el hardware y el software diseñado (al menos para +2A y +3).

En cuanto a los RSX, ESXDOS tiene algo muy parecido. Cada vez que se tropieza con un punto (como en .tapein), ESXDOS busca el comando correspondiente en el directorio /bin del disco y lo ejecuta. Ni siquiera hace falta tirar de ROM, lo tienes en la SD.

Por último está la pregunta filosófica del millón... ¿llegarán a utilizarlo los programadores? Tener 512k de RAM o de ROM está muy chulo, y los rusos hacen virguerías con sus clones de 256 y 512Kb, eso está claro. La pregunta de un programador típico sería... ¿hago el juego para 512Kb con sus desventajas (no mucha gente lo tiene y los emuladores no lo soportan todavía) o lo hago más pequeño para que quepa en 128Kb (y 128Kb dan para mucho)? ¿O hago como los de Level 9 y uso 128Kb y además tiro de disco como un loco? La multicarga de un sistema de disco no es muy lenta, e incluso utilizando solo dos caras de un disco de 3 pulgadas dan para bastante.

[mcleod_ideafix]

...¿hago el juego para 512Kb con sus desventajas (no mucha gente lo tiene y los emuladores no lo soportan todavía)...

Ahí la has dado. Si el éxito de esta propuesta depende exclusivamente de que se haga software nuevo que aproveche este nuevo hardware, te das con un canto en los dientes, por la sencilla razón de que no hay emulador que soporte el sistema de bankeo de ROMs que propones.

El programador en cuestión tendría que, o bien tener tu interface, y trabajar contra el sistema real (lo cual es mucho menos cómodo que hacerlo con emulador), o bien hacer "trampa" y trabajar con 512KB de RAM en lugar de ROM usando emulación de Pentagon o algo similar, para luego convertir el programa a ROM recompilándolo o algo por el estilo.

A efectos prácticos, diseñar una interface nueva sin soporte alguno en emulador, y sin software o framework, es muy muy arriesgado, y te enfrentas a que dichas características (y tu interfaz) sean completamente ignoradas por la mayoría de programadores. Mira que hasta que Spectranet no ha sido emulado en Fuse no han empezado a aparecer cositas hechas para él. Hasta entonces, lo único que había era lo que el propio Winston había hecho.

Por otro lado, la interface Spectra, de Paul Farrow, no tiene soporte en ningún emulador, que yo sepa, lo que significa que no hay NADA para ella, que no sea lo que el propio Paul haya hecho.

Mentira, sí lo tiene, en dos emuladores. Mea culpa no haberlo chequeado mejor.

El mismo modo "Radastaniano" del ZX-Uno no tendría ninguna chicha si no fuera porque Antonio Villena lo tiene emulado en JBacteria, lo que le está permitiendo al propio Radastan hacer su juego aunque aún no disponga de un ZX-Uno real.
http://es.paperblog.com/se-filtran-en-t ... o-2769742/

Cosas como el DivIDE o el DivMMC con ESX-DOS tienen éxito por dos razones:
- Tal y como está, le vale a cualquier usuario y vale con el software existente
- Está emulado, con lo que se puede crear nuevo software para este sistema aunque no lo tengas fisicamente, y además con la comodidad de trabajar en un emulador, con su depurador, sus puntos de ruptura, etc.

Pero tu propuesta de ROM de 512KB no cumple con ninguna de las dos cosas anteriores.

[cheveron]

Trying to map extra RAM into the Z80's 64K address space without a memory management unit is always going to be a headache, no matter how you do it. Even using the extra RAM on the 128 is a pain. At least on the Chloe 280SE (supported by ZX-Uno) you get two sideways pages of 64K that can be paged in in chunks. Bur really the best solution is to write for esxDOS. It is the only OS supported by divMMC but it also runs on divIDE and there are hundreds of those around. divIDE is also supported in emulators which makes development much easier.

On the subject of new graphics modes ... the 8x1 Timex mode has been around since 1983 and no commercial software ever used it. Inventing new modes is easy. Getting them emulated is tricky. Getting people to write software for them is virtually impossible.

[mcleod_ideafix]

On the subject of new graphics modes ... the 8x1 Timex mode has been around since 1983 and no commercial software ever used it. Inventing new modes is easy. Getting them emulated is tricky. Getting people to write software for them is virtually impossible.

Let me translate this parragraph for you, Andrew

...El mismo modo "Radastaniano" del ZX-Uno no tendría ninguna chicha si no fuera porque Antonio Villena lo tiene emulado en JBacteria, lo que le está permitiendo al propio Radastan hacer su juego aunque aún no disponga de un ZX-Uno real.

... The very "Radastanian" graph mode implemented in ZX-Uno would be worthless if it were not for the work Antonio did to implement it in its JBacteria emulator, which in turn it's what is allowing Radastan to finish his game even if he still has not a real ZX-Uno computer.

So there is an emulator that includes this mode, and there is at least one developer who is working with it AFAIK, we have more developers than Paul Farrow has, working with the new graphic modes of Spectra

The 8x1 Timex HiColor is awesome, but...
- You still have some colour clash. "Radastan" mode gives you true individual-colour-per-pixel as expense of lowering the spatial resolution.
- You loose 6K of memory compared to the original ULA mode, or the "Radastanian" mode, which uses only 6144 bytes (not even 6912).
- You have to move twice the amount of memory to draw a sprite, with the same CPU at the same speed. A byte in Radastan mode holds two pixels instead of eight, but the sprites need less pixels to get an apparent size because pixels are bigger, and you can play with the colour to enhance details in your graphics.

[cheveron]

Let me translate this parragraph for you, Andrew

... The very "Radastanian" graph mode implemented in ZX-Uno would be worthless if it were not for the work Antonio did to implement it in its JBacteria emulator, which in turn it's what is allowing Radastan to finish his game even if he still has not a real ZX-Uno computer.

So there is an emulator that includes this mode, and there is at least one developer who is working with it AFAIK, we have more developers than Paul Farrow has, working with the new graphic modes of Spectra

Yes well as far as I know, no-one is doing anything on Spectra any more.

The 8x1 Timex HiColor is awesome, but...
- You still have some colour clash. "Radastan" mode gives you true individual-colour-per-pixel as expense of lowering the spatial resolution.
- You loose 6K of memory compared to the original ULA mode, or the "Radastanian" mode, which uses only 6144 bytes (not even 6912).
- You have to move twice the amount of memory to draw a sprite, with the same CPU at the same speed. A byte in Radastan mode holds two pixels instead of eight, but the sprites need less pixels to get an apparent size because pixels are bigger, and you can play with the colour to enhance details in your graphics.

Well yes but, on the Chloe you can use bank 7 and have the video outside the normal address space. Also as you know, with ULAplus the color clash is often barely noticeable. And finally you don't always have to update the attributes and the bitmap at the same time. As soon as I get my hands on a working zxuno with full Chloe 280SE support I'm planning on making plenty of use of the Timex modes with ULAplus.

[hikoki]

En wos están discutiendo la idea de hacer un Monkey Island para el Spectrum, o incluso portar el motor de SCUMM.
Podría ser esta una buena oportunidad para popularizar el interface Superupgrade ?

[wilco2009]

Gracias por la sugerencia, igual me animo a traducir la documentación al inglés y publicarla en WOS.

De todas formas por lo que he podido leer, los tiros los llevan más por utilizar un medio tipo divIDE.

[ben-kenobi]

Seria lo lógico , usar el divide para poder usar cargas no secuenciales sin retardo.

[hikoki]

Vale, pero disculpad mi ignorancia, el divide permite cargar todos los juegos desde cualquier máquina ? Es que a mi solo me pone el señor Sinclair, el señor Sugar no me entra bien.
La idea de un cartucho físico también es bonita.

[wilco2009]

Para que te funcione en los modelos +2a en adelante tienes que dejar puesto el jumper de la derecha.
Efectivamente estoy de acuerdo en que un cartucho de 512kb molaria un monton, falta que los demás están de acuerdo conmigo.

[hikoki]

Encuesta en WoS ?

[ben-kenobi]

Yo estaría encantado con lo del cartucho, siempre que también sirviera para los "azucarados"