Netlists and Other News (Patreon)

Español abajo

Several SEGA System 18 games are booting up in the upcoming JTS18 core but I found an unexpected hiccup in the connection of the MegaDrive VDP. This arcade system uses a combination of video chips in which the MegaDrive VDP also plays a role. We have two versions of this VDP available, which you may have already experienced in the old and the new MegaDrive cores for the MiSTer. Sadly, there is something going on messing up what should just have been a simple plug and play step. Debugging this took most of the week with no luck. Without the VDP, some sprites are missing in Alien Storm. The VDP also seems to play a role in choosing the right background tiles used for the other video chips so the video looks all garbled. Work on this continues.

An interesting topic about the MegaDrive VDP is whether or not we should use netlists for FPGA cores. The new MegaDrive MiSTer core is largely a netlist of a MegaDrive board and chips. A netlist is a technical term for a file that lists electrical nets and how they connect to each other. A netlist of an original system is as close as you can get in recreating that system. But, it poses a legal question as you are basically using the original design with minimum changes. Compatible systems have been legally allowed based on the clean-room principle, where you design the compatible system from scratch and similarities with the reference design are accepted only where there is a single reasonable technical solution.

The second problem is that these netlists per-se do not teach you anything about the system. If you look at the file you will only see thousands of cryptic names connected in a very low level way. The function of the device cannot be inferred from just reading the file. This is the opposite to regular design files where functionality is easy to grasp for expert eyes. So you may have a black box that does what it is supposed to do, albeit transcription errors, but you have learnt nothing about the system. It is like a Rosetta stone with no Jean-François Champollion.

A final problem with these netlists is that they tend to be challenging for the FPGA because the underlying digital primitives are different for an FPGA and an 80/90's ASIC. In the case of the MegaDrive VDP this was worked around by operating the netlist at twice the original frequency, which forces the whole MegaDrive core to be synthesized at over 100 MHz. This is a troublesome frequency that makes the core less portable and reliable. Similarly, the original VDP chip worked with external RAM memories that had a very peculiar serial/parallel interface with multiplexed input ports. If you use a netlist, you must keep that interface. The only option you pretty much have to implement it is to use the internal FPGA memory. Because of the large RAM needed, the new MegaDrive core does not work on smaller FPGA chips, although these were large enough to operate the older core.

To stop doing netlists from chip die shots is not the solution for these problems. I think these netlists have a critical role in research. But, I think we should aim to always design new compatible modules that are unchallenged intelectual property of their authors. Modules that clearly express the chip behavior and purpose. Finally, these modules should be well suited for modern electronic devices, without forcing users to buy expensive FPGA hardware when much cheaper options should suffice. This can be done without compromising accuracy, especially because having the reference netlists allows for easy comparison and refinement.

Other updates

• Some Konami games draw black frames around the image, making it smaller than expected from pure hardware blanking signals. These frames are software dependent and may not exist at all or be 8 or 16 pixels wide. We have made modifications to the JTFRAME framework to be able to remove these frames on a per-game basis. This applies to MiSTer (HDMI output) and Pocket users in games such as Vendetta and The Simpsons, which will look larger chunk after today's update.

• A couple of small graphical glitches in OutRun were fixed. No good solution for the problems some Pocket users have on this title yet, though.

• Karate Champ VS games can be played using four joysticks now

• The problems with Toki JSON files and Toki wrong PCM pitch are solved now. The credits screen is also enabled. Note that this core comes from Solal who is the first external author developing and publishing directly in the JTCORES repository. We are hoping more will come to take advantage of the JTFRAME framework

That is all for this week. Thanks again for funding this project.

Español

Varios juegos del Sistema 18 de SEGA arrancan en el futuro núcleo JTST18, pero me topé con un contratiempo en la conexión del VDP de MegaDrive. Este arcade utiliza una combinación de chips de vídeo en la que también interviene el VDP de MegaDrive. Disponemos de dos versiones de este VDP, que puede que ya hayas experimentado en el antiguo y el nuevo core de MegaDrive para la MiSTer. Lamentablemente, hay algo que fastidia lo que debería haber sido un simple paso de enchufar y listo. La depuración ha llevado casi toda la semana y sin suerte. Sin el VDP, faltan algunos sprites en Alien Storm. El VDP también parece jugar un papel en la elección de los bloques de fondo utilizados por los otros chips de vídeo. Así que el vídeo se ve todo mal. Seguimos en ello.

Un tema interesante sobre el VDP de MegaDrive es si debemos o no utilizar netlists para los núcleos FPGA. El nuevo núcleo MegaDrive MiSTer es en gran parte un netlist inmenso de una placa MegaDrive y sus chips. Un netlist es un término técnico para un archivo que enumera nodos eléctricos y cómo se conectan entre sí. Una lista de redes (netlist) de un sistema original es lo más parecido a recrear ese sistema. Pero plantea una cuestión legal, ya que básicamente se está utilizando el diseño original con cambios mínimos. Los sistemas compatibles se han permitido legalmente basándose en el principio de sala limpia, según el cual se diseña el sistema compatible desde cero y las similitudes con el diseño de referencia sólo se aceptan cuando existe una única solución técnica razonable.

El segundo problema es que estos netlists por sí mismos no enseñan nada sobre el sistema. Si miras el archivo, sólo verás miles de nombres crípticos y relaciones matemáticas simples. La función del dispositivo no puede deducirse de la lectura del archivo. Esto es lo contrario de lo que ocurre con los archivos de diseño normales, en los que la funcionalidad es fácil de comprender para ojos expertos. Así que puedes tener una caja negra que hace lo que se supone que debe hacer, salvo errores de transcripción, pero no has aprendido nada sobre el sistema. Es como una piedra Rosetta sin Jean-François Champollion.

Un último problema con estos netlists es que suelen ser problemáticos para la FPGA porque las primitivas digitales subyacentes son diferentes para una FPGA y un ASIC de los 80/90. En el caso del VDP de MegaDrive, esto se solucionó haciendo funcionar el netlist al doble de la frecuencia original, lo que obliga a sintetizar todo el núcleo de MegaDrive a más de 100 MHz. Se trata de una frecuencia excesiva que hace que el núcleo sea menos portátil y fiable. Del mismo modo, el chip VDP original funcionaba con memorias RAM externas que tenían una interfaz serie/paralelo muy peculiar con puertos de entrada multiplexados. Si utilizas un netlist, debes mantener esa interfaz. La única opción que tienes para implementarla es utilizar la memoria interna de la FPGA. Debido a la gran cantidad de RAM necesaria, el nuevo núcleo de MegaDrive no funciona en chips FPGA más pequeños, aunque éstos sean lo suficientemente grandes como para hacer funcionar el núcleo anterior (con VDP rediseñado) sin problemas.

Dejar de hacer netlists a partir de fotos de chips no es la solución para estos problemas. Creo que estos netlists tienen un papel fundamental en la investigación. Pero, que deberíamos aspirar a diseñar siempre nuevos módulos compatibles que sean propiedad intelectual indiscutible de sus autores. Módulos que expresen claramente el comportamiento y la finalidad del chip. Por último, estos módulos deberían adaptarse bien a los dispositivos electrónicos modernos, sin obligar a los usuarios a comprar hardware FPGA caro cuando basta con opciones mucho más baratas. Esto puede hacerse sin comprometer la precisión, sobre todo porque al disponer de los netlists de referencia podemos comparar los nuevos diseños y perfeccionarlos fácilmente.

Otras mejoras

• Algunos juegos de Konami dibujan marcos negros alrededor de la imagen, haciéndola más pequeña de lo esperado a partir de señales de blanking del hardware. Estos marcos dependen del software y pueden no existir en absoluto o tener 8 o 16 píxeles de ancho. Hemos realizado modificaciones en el marco JTFRAME para poder eliminar estos marcos en cada juego. Esto aplica a los usuarios de MiSTer (salida HDMI) y Pocket en juegos como Vendetta y Los Simpson, que se verán más grandes tras la actualización de hoy.

• Se han solucionado un par de pequeños fallos gráficos en OutRun. Aunque todavía no hay una buena solución para los problemas que algunos usuarios de Pocket tienen en este título.

• Las partidas de Karate Champ VS se pueden jugar con cuatro joysticks ahora

• Los problemas con Toki JSON files y Toki wrong PCM pitch ya están solucionados. La pantalla de créditos también está habilitada. Nótese que este núcleo proviene de Solal que es el primer autor externo que desarrolla y publica directamente en el repositorio JTCORES. Esperamos que vengan más para aprovechar el framework JTFRAME.

Esto es todo por esta semana. Gracias de nuevo por financiar este proyecto.