La respuesta siempre fue la Megadrive

CLICK HERE FOR ENGLISH VERSION

 

iconos_dbf_megadrive_y_TV

Sega diseñó la Megadrive para poder conectar varios periféricos y ampliar sus capacidades. ¿Es posible hoy ampliar las capacidades de la consola?
¿Podemos crear un add-on que cumpla estos requisitos?

  • Ser fácil de usar. Enchufar y listo. Sin soldaduras.
  • Ser viable y económico.
  • Ser sencillo de programar. Scene friendly.

Tengo una propuesta.

LOS ADD-ONS OFICIALES

Repasemos las 3 expansiones más importantes que Sega sacó al mercado.

iconos_dbf_megadrive_megacd_TV

MEGA CD / SEGA CD

El Mega CD hace rotaciones, scaling y FMV (+audio cd). No obstante al no tener salida de vídeo propia, todo ha de enviarse en forma de tiles por el bus principal del sistema. En juegos clásicos (Sonic CD, Batman Returns) el ancho de banda del bus es suficiente, sólo necesitamos manipular un número limitado de tiles. En juegos FMV no es así

Además, al seguir dependiendo del VDP de la Megadrive y de su C-RAM, la limitación de paletas y colores sigue presente.

Un CD es extremadamente barato de fabricar y además su capacidad excede con mucho a la del cartucho más grande disponible. Esa es la idea principal para lanzar un lector de cedes. Pero al igual que en su época, el Mega CD es caro, y hoy día el CD ha sido reemplazado por otras tecnologías.

Aunque pudiésemos crear algo parecido a un Mega CD a un precio razonable, la limitación del bus y las limitaciones del VDP de la negrita seguirían presentes.

Image1

SVP

El SVP modela una escena 3D y a partir de ella crea una imagen 2D. Como en el Mega CD, esta imagen se pasa en forma de tiles a la VRAM del VDP de la negrita a través del bus.

La forma de comunicarse del SVP con la megadrive es cuanto menos curiosa. Existen una serie de registros a través de los cuales pueden mandarse tanto señales de aviso (“quiero que ejecutes la rutina 3 de la ROM”), como pasarse información. Aparentemente no se mapea directamente en memoria como el mega CD.

Aún así seguimos dependiendo del VDP de la negrita y del bus del sistema. Mismas limitaciones.

La documentación es *casi* inexistente. Sabemos algunas cosas gracias a la scene pero estamos lejos de poder dominar el SVP.

Por otro lado, coger cartuchos de VR y flashear su ROM no es plug-n-play.

iconos_dbf_megadrive_32X_TV

32X

El 32X utiliza su propio “Súper” VDP+salida de vídeo para conectarse a la TV. Las limitaciones del VDP de la Megadrive ya no son un problema.

El 32X mezcla su señal audio/vídeo con la señal audio/vídeo de la Megadrive: Para cada píxel de la imagen, se consulta el bit de prioridad del Super VDP del 32X, pintando entonces con la señal RGB de la negrita o con la señal RGB del 32X.

Es una genial idea para tener dos sistemas funcionando al mismo tiempo sin molestarse demasiado. De esta forma pueden colaborar. Para ello el 32X se mapea en la dirección de memoria de la megadrive, de esta forma se comunican, no usa registros como el SVP.

Existen por tanto una serie de direcciones de memoria (desde 0x20 – 0x2F) donde todos los actores (SH-2 maestro, SH-2 esclavo, 68k). Así si el SH2 maestro escribe “1234” en 0x20, a continuación tanto el 68k como el SH2 esclavo lo pueden leer.

Sin embargo el 32X tuvo y tiene grandes inconvenientes.

Para empezar es caro, vendió muy poco y eso lo descarta.
Y pensando en la escena, aprender a programar los SH-2, con su configuración maestro-esclavo, puede ser complicado. Además el VDP del 32X no puede gestionar sprites, no existen, todo deben hacerlo los SH2 y, por tanto, todo debe hacerse a mano. No compensa el aumento de potencia desde el momento que no hay apenas scene para el 32X.

 

LA PROPUESTA

Propongo usar, irónicamente, vieja tecnología. Ni SH-2, ni SVP, ni Mega CD. ¿Qué es lo que domina la Scene? Señores, la megadrive misma. La scene de la megadrive es más activa que nunca. Y su fuerza es la propia megadrive.

Mi propuesta es utilizar otra megadrive como segundo sistema. MD^2.

Dos sistemas iguales  y (casi) independientes, además de un mezclador para juntar señales de vídeo+audio.

Nos saltamos las limitaciones del bus y del VDP porque no vamos a usar el bus para mandar tiles. Cada sistema dibuja por su cuenta sin molestarse. Por supuesto ambos sistemas deberían comunicarse, utilizando el bus lo mínimo posible.

 

¿Por qué usar otra cosa que no sea otra megadrive? 
En consecuencia hablamos de tener DOS megadrives.
  1. Una megadrive clásica, aka MDx1. Es decir, una megadrive física.
  2. Una megadrive virtual, aka MDx2. Por definir, por eso estamos aquí.

iconos_dbf_megadrive_dual.png

MD^2 = MDx1 + MDx2

 

¿Estamos locos? ¿Por qué hacer esto?

¿Por qué buscar algo nuevo cuando tenemos algo que funciona? Si usamos otra megadrive, instantáneamente todo lo que existe tiene valor: Documentación, SGDKs y similares, foros activos, programadores, grafistas, músicos, emuladores, etc.

No hay que aprender y desarrollar nada nuevo, lo que tenemos ya funciona.

Si usamos dos megadrives, podemos especializarlas.

Matamarcianos: la MDx1 haría fondos y los marcadores, ríete del parallax del TF4, puedes dedicar casi todos los recursos (fondos, sprites, paletas) a los fondos. La MDx2 en cambio, se dedicaría al juego en sí. Nave, enemigos, disparos. Bullet hell. Incluso podría utilizar un fondo entero para poner un enemigo gigante.

Juego carreras estilo Out run: la MDx1 para los fondos, marcador y todo lo que aparece en la carretera, la MDx2 para los coches exclusivamente. De esta forma podemos tener muchos sprites de varios tamaños, tanto de los coches como de los elementos que aparecen en losfondos, y hacer un pseudo-scaling mucho más realista.

Juego musical: Una megadrive puede dedicarse por completo a la música, y la otra para el resto del juego.

Juego modo 7: una megadrive hace el plano abatido, el resto del juego lo hace la otra.

Y así podemos poner muchos ejemplos.

4 paletas + 4 paletas señores. El colorido de los juegos puede ser mucho más amplio, manteniendo el funcionamiento del VDP.

Al poder comunicarse ambas consolas, podemos hacer cosas impensables para una sola consola.

Por supuesto, las ROMS serían un tanto diferente, porque harían falta 2 ROMS por juego (dual ROM).

¿Cómo comunicamos las consolas?

No sabría decirlo. Mi apuesta es mapear la MDx2 en la MDx1 tal y como hace el 32X.

Mínima comunicación. Una consola no debe meterse en lo que hace la otra, no más colisiones SH-2. No más complicarse la vida.

Por ejemplo, si una consola hace un scroll parallax, la otra debe informar cuando se mueve el personaje para actualizar el scroll. nada más.

 

¿La segunda consola va a ser una megadrive real?

No, nadie va a tener dos consolas reales juntas. MDx2 debe tener forma de cartucho, aunque sea más grande, con lector de tarjetas SD e idealmente un slot de cartuchos de megadrive.

Como el 32X, debe tener un RGB input y un RGB output.

 

¿Cómo lo implementamos?

¿FPGAs? ¿GOACs? ¿EMU corriendo en HW arm tipo móvil?

Creo que una FPGA añadiendo el integrado para mezclar la imagen tal y como hace el 32X sería lo ideal.

Ignoro si el slot de cartuchos de la megadrive puede dar la suficiente corriente para que una FPGA funcione sin utilizar una fuente de alimentación adicional.

El dispositivo debe ser de un tamaño que no moleste tenerlo todo el tiempo conectado. Existen dispositivos hoy en el mercado que hacen cosas parecidas.

A día de hoy, creo que sería buena idea NO PONER HW DE SONIDO en la MDx2 ya que los cores de FPGA de Megadrive van bastante mal, además se ahorra dinero al no ponerlo.

 

El mezclador

Éste es el integrado que hace la magia en la 32X. Es el IC 315-5788.

32x_mix_video.png

Arriba las entradas RBG de dos sistemas (pins 4-9). Abajo la salida RGB final (pins 27,28,29). Se usa un color de Chroma para hacer la imagen transparente.

Sería cuestión de buscar algo parecido más estándar, no un custom IC de Sega. O quizá pueda implementarse en la FPGA.

 

Software

El software actual funciona sin cambios para hacer las roms individuales.

Sería necesario hacer pequeños cambios para MD^2.

Un emulador debería correr dos instancias y ser capaz de mezclar las imágenes, además de simular el envío de datos entre MDx1 y MDx2.

El software de desarrollo debería incluir formas sencillas de mandar datos entre consolas.

No hace falta más.

 

 


 

English Version

iconos_dbf_megadrive_y_TV

Sega Megadrive/Genesis was designed to be connected with several peripherals and expand their capabilities. Is it possible today to expand its capabilities?
Can we create an add-on that meets these requirements?

  • Easy to use. Plug’n’Play. No manual welds.
  • Cheap, realist.
  • Easy to program. Scene friendly.

I have a proposal.

 

THE OFFICIAL ADD-ONS

Let’s review the 3 most important expansions that Sega brought to market.

iconos_dbf_megadrive_megacd_TV

MEGA CD / SEGA CD

Mega/Sega CD makes rotation, scaling and FMV (+audio cd). However, since it does not have its own video output, everything has to be sent in the form of tiles through the main bus. In classic games (Sonic CD, Batman Returns) bandwidth is enough, we just need to manipulate a limited number of tiles. In FMV games is not enough.

Also we still using Megadrive VDP and its C-RAM, pal limitations still present.

A CD is extremely cheap to manufacture and its capacity far exceeds the largest cartridge available. That is the main idea to launch a CD reader. But Mega CD was expensive, and today still is. Today, CD has been replaced by other technologies.

We could create something similar to a Mega CD at a reasonable price, bus bottleneck and VDP limits would still there.

Image1

SVP

SVP models a 3D scene and then makes a 2D image. Like Mega CD, this image goes tile-by-tile to VDP’s VRAM, travelling across the bus.

SVP was of communicacion with Megadrive is curious. Apparently it is not mapped directly in memory like the mega CD. There are some registers that can be use to pass info between both, also Megadrive can ask SVP to do some stuff (“I want you to run routine 3 of the ROM”).

But bus bottleneck and VDP limits would still there.

Focumentation is * almost * non-existent. We know some things thanks to the scene but we are far from being able to dominate the SVP.

On the other hand, picking up VR cartridges and flashing your ROM is not plug-n-play.

iconos_dbf_megadrive_32X_TV

32X

32X uses its own “Super” VDP video output to connect with TV. Megadrive VDP’s bottleneck is not longer a problem.

32X mixes its audio / video signal with the Megadrive audio / video signal: For each screen pixel, Super VDP priority bit selects which “to paint”, 32X RGB signal or Megadrive RGB signal.

It’s a great idea. Two systems running at the same time without bothering too much. This way they can collaborate. 32X is mapped in Megadrive memory map, this way they communicate, not using registers like SVP.

There are some memory addresses (from 0x20 – 0x2F) where all the actors (SH-2 master, SH-2 slave, 68k) can write or read. If the SH-2 master  writes “1234” in 0x20, then both  68k and slave SH-2 can read it.

However the 32X had and has major drawbacks.

It is expensive, sold in low numbers. Also learning to program SH-2, with its master-slave configuration, can be complicated. In addition, the 32X VDP cannot manage sprites, they do not exist, everything must be managed by SH-2, “by hand”.

Does SH-2 extra power worth it?  Almost no scene for the 32X.

 

THE PROPOSAL

 

I propose to use, ironically, old technology. Not SH-2, not SVP, not Mega CD. What dominates the Scene? Gentlemen, the megadrive itself. The megadrive scene is more active than ever. And its strength is the megadrive itself.

I propose to use another Megadrive as second system. MD^2.

Two identical systems (almost) independent, mixing video+audio signals.

Doing this, we skip bus bottlenecks and VDP limitations, because we are not going to use the bus to send tiles. Each system draws its contents without disturbing the other.
Of course both systems should communicate, using the bus as little as possible.

 

Why use other THING than another Megadrive?
Consequently we talk about TWO Megadrives.

 

  1. A classic megadrive, aka MDx1. That is, a REAL megadrive.
  2. A virtual megadrive, aka MDx2. To be defined, that’s why we are here.

 

iconos_dbf_megadrive_dual.png

MD^2 = MDx1 + MDx2

Are we crazy? Why doing this?

Why look for something new when we have something that works? If we use another Megadrive, everything is working: Documentation, SGDK, active forums, active programmers, graphic artists, musicians, working emulators, etc.

No need to learn and develop new things, what we have already works.

If we use two mega-drives, we can manage games in different ways.

Shoot ‘em up Game:  MDx1 could make backgrounds + detailed parallax scrolls (TF4 style), this way MDx1 can use all its resources (backgrounds, sprites, palettes) to do it.
MDx2 instead, would use all its resources to game itself. Bullet hell. Still can use one plane to gigant enemy.

Out Run Game: MDx1 for backgrounds, UI. MDx2 for cars exclusively. This way MDx2 could manage many sprites / different sizes, cars and backgrounds elements, realistic pseudo-scaling.

Music game: One Megadrive can be use only for music, and the other the game.

Mode 7 game: One Megadrive will do the mode 7 plane, rest of the game is manage by the other Megadrive.

And so on.

4 pals + 4 pals gentlemen. 64 + 64 colors. With same pal management.

As both machines could send data to the other, we can do new things that only 1 machine can’t do.

Of course, ROMS would be somewhat different, because 2 ROMS would be needed per game (dual ROMs).

 

How to connect both systems?

Not sure. My bet is map MDx2 into MDx1 like 32X does.

Minimal comunication. One system won’t try to bother other one.
No more complicated things, like SH-2 collisions.

I.e one system makes parallax scroll, other system will inform about movement to update scroll when needed. Nothing more.

 

MDx2 to be a real-physical Megadrive?

No, nobody would play with two real Megadrive together. MDx2 needs to be like a big cartridge, with SD slot, and, if posssible, megadrive cartridge slot.

Like 32X, RGB input and RGB output.

 

How to implement?

¿FPGAs? ¿GOACs? ¿Emulator into HW ARM mobile like?

I think FPGA + mixing IC will be perfect.

I don’t know if Megadrive slot could manage enough current to provide FPGA current like a power supply

MD^2 size must be ok to be connected all the time.
There are devices on the market today that do similar things with good size.

I think NO SOUND in MDx2 will be better, to avoid problems (as megadrive FPGA cores have bad sound) and also reduce cost.

 

IC Mixer

32X like. This is IC 315-5788.

32x_mix_video.png

In the up part input RBG (pins 4-9). Down part output RGB (pins 27,28,29). One chroma color used to made transparency.

We need to look for something similar, not this custom IC. But maybe could be into the FPGA.

 

Software

Actual software works to make single roms.

Small changes needed for MD^2:

Update emulators to have 2 instances running, mixing audio/video and ‘send’ data between MDx1 y MDx2.

Developer software must include easy-to-do functions to send data between MDs.

 

What do you think?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s