MCU Time! Bubble Bobble, Tokio, Renegade... (Patreon)

Español abajo

When I made the JTBUBL (Bubble Bobble, Tokio) core, I had  to limit it to certain game versions that used a MCU (Micro Controller  Unit) for which I had found a Verilog module. That meant putting the  original Tokio version aside and working only with the bootleg. The same  happened with Renegade too, where I had to hide the MRA for the  original version and use one for a bootleg instead. Not only that was a  limitation I didn't like. But, I also had no idea whether the MCU module  I was using was cycle accurate.

Come forward to Halloween 2023, I presented JTSHOUSE,  featuring Splatter House support on FPGA. It worked using the same MCU  with some patches as I had discovered several things:

• The family of 680x MCUs have non trivial differences among its  members. In some cases akin to comparing a 80286 with a 8086, in Intel  terms
• Hitachi made a parallel family of MCUs, the 630x. At first sight you  would think they just cloned everything. But, they didn't. They  increased performance and added new instructions.

About the same time, LordBarker80, a patron and  proud owner of a Japanese Bubble Bobble board, contacted me about  slowness in the core, compared to his system. Again, the smoking gun was  that MCU implementation.

It was clear that I needed to have my own modules for all  these MCUs (at least four models for now). But my experience designing  CPUs has been a mixed bag. QSound's DSP16 wasn't too bad but the NeoGeo  Pocket CPU was a hard design that got even more complicated when I tried  to work on it with an unexperienced team. Having learnt from that, I  approached the Konami CPU using a mix of 50% microcode, 50% hardware.  That went much better.

Microcoding is a digital design technique were the  sequencing of a state machine (such as a CPU) is encoded in a memory.  The way you describe the entries in the memory has some resemblance to  assembly code, hence the term. Microcoding is more readable, debuggable  and understandable than regular digital logic. Making debugging as less  painful as possible is a design priority for me, after the NGP  experience. So this time I tried a more radical approach:

• Minimize the hardware side of the CPU
• Do as much as possible as microcode
• Ensure cycle accuracy by automating its verification and correction

With these design goals, I wrote my own automation tools  and got three radically different MCU models (MC6801, MC6805 and  HD63701Y0) working in just two weeks. With this approach, all these MCUs  are cycle accurate by construction (even the interrupt service timing  is exact). My tools even print a report of the number of clock ticks  that each processor instruction takes and compare it to the  specification. I have attached images of these reports for the three  devices. Thanks to this new development, we now have support for the  original game versions that relied on an MCU:

New Supported Versions

• Renegade (US)
• Nekketsu Kouha Kunio-kun (Japan)
• Tokio / Scramble Formation (newer)
• Tokio / Scramble Formation (older)
• Tokio / Scramble Formation (US)
• Bubble Bobble (prototype on Tokio hardware)

About the speed discrepancy,  LordBarker80 and I went back and forth testing new core iterations. The  old JTBUBL (version v1.3.2) had a delay of 2.85" after 9'24", or  roughly 85 microseconds/frame. The new version delay is only 30 microseconds/frame.  This is a huge improvement, as we have more than halved the speed  difference. But, I was expecting it to be perfect. I thought the crystal  oscillator in the Bubble Bobble board may have become faster over time  (a phenomenon called aging in the industry). But after measuring a few boards in our lab, aging could only account for 0.02% or some 3  microseconds/frame. So there must be something else going on. Now that I  am confident that the MCU is reliably built, I can double check other  items in the core.

This new approach and tools will be applied to Splatter  House and Double Dragon, fixing the MCU accuracy in both of them. There  are many other games that directly use the same MCUs. Just to mention a  few for which I already have traction on:

• The Fairy Land Story (Taito)
• Rolling Thunder (Namco)
• Kick'n Run (Taito)

I am also going to apply this approach to the NeoGeo Pocket CPU and re-design it from scratch. I think it will be faster and more  enjoyable than to continue debugging the current core. So, yes that core  was on hold while I was looking for a way to tackle the CPU debugging.  This is the approach I needed.

Update to Patreon Tiers

As I announced in October, I have modified the entry-level  tiers for new members. I want to say thanks to long-time supporters by  keeping their tier price fixed. Current members will not see changes to  their tier and price.

Español

Cuando hice el núcleo JTBUBL (Bubble Bobble, Tokio), tuve  que limitarlo a ciertas versiones del juego que utilizaban una MCU  (Micro Controller Unit) para la que había encontrado un módulo Verilog.  Eso significó dejar de lado la versión original de Tokio y trabajar sólo  con la pirata. Lo mismo ocurrió con Renegade, en el que tuve que  ocultar el MRA de la versión original y utilizar en su lugar uno pirata.  No sólo era una limitación que no me gustaba. Además, no tenía ni idea  de si el módulo MCU que utilizaba era preciso para el ciclo.

Llegados a Halloween de 2023, presenté JTSHOUSE, con  soporte para Splatter House en FPGA. Funcionó usando la misma MCU con  algunos parches, ya que había descubierto varias cosas:

• La familia de MCUs 680x tiene diferencias no triviales entre sus  miembros. En algunos casos es como comparar un 80286 con un 8086, en  términos de Intel.
• Hitachi creó una familia paralela de MCUs, la 630x. A primera vista,  se podría pensar que lo han clonado todo. Pero no lo hicieron.  Aumentaron el rendimiento y añadieron nuevas instrucciones.

Más o menos al mismo tiempo, LordBarker80, un  mecenas y orgulloso propietario de una placa japonesa Bubble Bobble, se  puso en contacto conmigo acerca de la lentitud del núcleo, en  comparación con su sistema. De nuevo, la pistola humeante era la  implementación de la MCU.

Estaba claro que necesitaba tener mis propios módulos para  todas estas MCUs (al menos cuatro modelos por ahora). Pero mi  experiencia diseñando CPUs ha sido una de cal y una de arena. El DSP16  de QSound no fue difícil, pero la CPU de la NeoGeo Pocket era un diseño  muy enrevesado que se complicó aún más cuando intenté trabajar en él con  un equipo sin experiencia. Tras aprender de aquello, abordé la CPU de  Konami utilizando una mezcla de 50% de microcódigo y 50% de hardware.  Eso fue mucho mejor.

El microcódigo es una técnica de diseño digital en la que  la secuencia de una máquina de estados (como una CPU) se codifica en una  memoria. La forma de describir las entradas en la memoria tiene cierto  parecido con el código ensamblador, de ahí el término. La  microcodificación es más legible, depurable y comprensible que la lógica  digital normal. Hacer la depuración lo menos dolorosa posible es una  prioridad de diseño para mí, después de la experiencia con la NGP. Así  que esta vez he intentado un enfoque más radical:

• Minimizar el lado hardware de la CPU
• Hacer lo más posible en microcódigo
• Asegurar la precisión del ciclo automatizando su verificación y corrección

Con estos objetivos de diseño, escribí mis propias  herramientas de automatización y conseguí que tres modelos de MCU  radicalmente diferentes (MC6801, MC6805 y HD63701Y0) funcionaran en sólo  dos semanas. Con este enfoque, todos estos MCU son precisos en cuanto  al ciclo (incluso la temporización del servicio de interrupción es  exacta). Mis herramientas incluso imprimen un informe del número de  pulsaciones de reloj que tarda cada instrucción del procesador y lo  comparan con la especificación. He adjuntado imágenes de estos informes  para los tres dispositivos. Gracias a este nuevo desarrollo, ahora  tenemos soporte para las versiones originales del juego que dependían de  una MCU:

Nuevas versiones soportadas

• Renegade (US)
• Nekketsu Kouha Kunio-kun (Japón)
• Tokio / Scramble Formation (más reciente)
• Tokio / Scramble Formation (antiguo)
• Tokio / Scramble Formation (US)
• Bubble Bobble (prototipo en hardware Tokio)

Acerca de la discrepancia de velocidad,  LordBarker80 y yo probando sucesivas iteraciones del núcleo. El antiguo  JTBUBL (versión v1.3.2) tenía un retardo de 2.85" después de 9'24", o  aproximadamente 85 microsegundos/fotograma. El retardo de la nueva versión es de sólo 30 microsegundos/fotograma.  Es una mejora enorme, ya que hemos reducido a menos de la mitad la  diferencia de velocidad. Pero esperaba que fuera perfecto. Pensé que el  oscilador de cristal de la placa Bubble Bobble podría haberse vuelto más  rápido con el tiempo (un fenómeno llamado envejecimiento en la  industria). Pero después de medir unas cuantas placas en nuestro laboratorio, el envejecimiento sólo podía explicar el 0,02% o  unos 3 microsegundos/fotograma. Así que tiene que haber algo más. Ahora  que estoy seguro de que la MCU está construida de forma fiable, puedo  volver a comprobar otros elementos del núcleo.

Este nuevo enfoque y herramientas se aplicarán a Splatter  House y Double Dragon, arreglando la precisión de la MCU en ambos. Hay  muchos otros juegos que utilizan directamente las mismas MCU. Por  mencionar sólo algunos que estamos mirando:

• The Fairy Land Story (Taito)
• Rolling Thunder (Namco)
• Kick'n Run (Taito)

También voy a aplicar este enfoque a la CPU de NeoGeo Pocket y rediseñarla desde cero. Creo que será más rápido y divertido que  seguir depurando el núcleo actual. Así que, sí, ese núcleo estaba en  espera mientras yo estaba buscando una manera de abordar la depuración  de la CPU. Este es el enfoque que necesitaba.

Actualización de los niveles de Patreon

Como anuncié en octubre, he modificado los niveles de  entrada para los nuevos miembros. Quiero dar las gracias a los que me  apoyan desde hace tiempo manteniendo fijo el precio de su nivel. Los  miembros actuales no verán cambios en su nivel y precio.