Out Run Beta, Vigilante for Pocket FPGA

FILES FOR MIST(ER) & SIDI ARE IN JTBIN

POCKET FILES ATTACHED

I am proud to announce the first Out Run beta. This system is a bit more complex than the usual despite supporting only two games (Out Run and Turbo Out Run). The board has two M68000 CPUs sharing a common memory and two road layers combined with the System 16B tile mappers. On top of that, there is also a very powerful sprite processing unit. All this makes this hardware a beast for its time.

Today’s beta won’t be the final one. The sprite hardware in the original uses a frame buffer to draw all sprites in a memory buffer while the previous image is dumped to screen. This is much more expensive than the common line buffer seen in pretty much every other arcade game. The line buffers also operate on the principle of drawing to a memory the next image while the current one is dumped to screen from another memory. But the line buffer only has memory for one line, whereas the frame buffer has memory for the full frame (usually 256 lines). This makes the frame buffer much more expensive. The frame buffer also introduces a 1-frame delay in the sprites, which requires the game logic to be designed with that in mind.

Frame buffers were needed when the ammount of sprites to draw in a single line was more than what the circuitry could handle. A common case are games where sprites could be used to draw background images. For instance, any element that shows a zooming effect in Out Run is a sprite. That includes everything around the roads (trees, sea waves, windmills, road signs…)

If you can operate your circuit logic at a very fast speed, it is possible to get away without the frame buffer. This is the preferred solution for modern FPGA systems because it reduces the board requirements. I did this for CPS2 and that’s why it can work in small systems like the MiST family. However, things didn’t go as well for Out Run. Even processing the video at 100MHz, there are some scenes so clutered that the line time finishes before all sprites have been parsed and that results in a missing line in the image.

100MHz is also a challenging speed for FPGAs so a lot of timing violations start to happen inside the system. A timing violation in digital circuits means that under some circumstances the signals either arrive too late or disappear too soon, so information may be lost. Overall, the line-buffer solution on a fast clock is not a solution for Out Run on FPGA. We need a real frame buffer.

Today’s beta operates using the line-buffer approach but I am working on the frame buffer one. The frame buffer is only possible on MiSTer and Pocket FPGAs. The MiST family doesn’t have a secondary RAM to store it. The NeptUNO family does have one, but the implementation for that system is a lower priority due to the tiny user count (sorry).

Note that the Super Hang-On core has been renamed to JTSHANON. It was JTOUTRUN before. This is due to the hardware differences between Out Run and Super Hang On. The later does not have a sprite frame buffer and does not suffer from the problems above. A couple of issues have been fixed for this system too so it’s a good candidate for a public release this month.

On other news, we get Vigilante for the Pocket today. So the PocketFPGA receives two games: Out Run and Vigilante. Note that Vigilante was already available for the other FPGA systems before, so we are just catching up.

Thanks for reading my technical rant and see you next week!

Español

Me enorgullece anunciar la primera versión beta de Out Run. Este sistema es un poco más complejo que el habitual a pesar de admitir solo dos juegos (Out Run y ​​Turbo Out Run). La placa tiene dos CPU M68000 que comparten una memoria común y dos capas de carreteras combinadas con los mapeadores de mosaicos System 16B. Además de eso, también hay una unidad de procesamiento de sprites muy potente. Todo esto hace de este hardware una bestia para su época.

La beta de hoy no será la definitiva. El hardware de sprites original usaba un framebuffer para dibujar todos los sprites en un búfer de memoria mientras la imagen anterior se volcaba a la pantalla. Esto es mucho más caro que el búfer de línea común que se ve en casi todos los demás juegos de arcade. Los búferes de línea también funcionan según el principio de dibujar en una memoria la imagen siguiente mientras que la imagen actual se vuelca a la pantalla desde otra memoria. Pero el búfer de línea solo tiene memoria para una línea, mientras que el framebuffer tiene memoria para el frame completo (generalmente 256 líneas). Debido a esto, es normal que framebuffer sea mucho más caro. El framebuffer también introduce un retraso de 1 frame en los sprites, lo que requiere que la lógica del juego se diseñe con eso en mente.

Se necesitaban framebuffers cuando la cantidad de sprites a dibujar en una sola línea eran más de los que podía manejar el circuito. Un caso común son los juegos en los que se pueden usar sprites para dibujar imágenes de fondo. Por ejemplo, cualquier elemento que muestre un efecto de zoom en Out Run es un sprite. Eso incluye todo lo que rodea las carreteras (árboles, olas del mar, molinos de viento, señales de tráfico...).

Se puede operar la lógica del circuito a una velocidad muy rápida, por lo que es posible que funcione sin el framebuffer. Esta es la solución preferida para los sistemas FPGA modernos porque reduce los requisitos de la placa. Hice esto para CPS2 y es por eso que puede funcionar en sistemas pequeños como la familia MiST. Sin embargo, las cosas no fueron tan bien para Out Run. Incluso procesando el video a 100 MHz, hay algunas escenas tan desordenadas que el tiempo de la línea finaliza antes de que se hayan analizado todos los sprites y eso da como resultado que falte una línea en la imagen.

100 MHz también es una velocidad desafiante para los FPGA, por lo que comienzan a ocurrir muchas violaciones de tiempo dentro del sistema. Una violación de tiempo en los circuitos digitales significa que, en algunas circunstancias, las señales llegan demasiado tarde o desaparecen demasiado pronto, por lo que se puede perder información. En general, la solución de búfer de línea en un reloj rápido no es una solución para Out Run en FPGA. Necesitamos un framebuffer real.

La versión beta de hoy funciona con el enfoque de búfer de línea, pero estoy trabajando en el de framebuffer. El framebuffer solo es posible en MiSTer y Pocket FPGA. La familia MiST no tiene una memoria RAM secundaria para almacenarla. La familia NeptUNO tiene uno, pero la implementación de ese sistema es de menor prioridad debido al pequeño número de usuarios (lo siento).

Tenga en cuenta que el núcleo Super Hang-On ha cambiado de nombre a JTSHANON. Antes era JTOUTRUN. Esto se debe a las diferencias de hardware entre Out Run y ​​Super Hang On. Este último no tiene un framebuffer de sprites y no sufre los problemas mencionados. También se han solucionado un par de problemas para este sistema, por lo que es un buen candidato para un lanzamiento público este mes.

¡Más noticias! Hoy tenemos Vigilante para la Pocket. Entonces PocketFPGA recibe dos juegos:  Out Run y ​​Vigilante. Tenga en cuenta que Vigilante ya estaba disponible para los otros sistemas FPGA antes, por lo que solo nos estamos poniendo al día.

¡Gracias por leer mi diatriba técnica y nos vemos la próxima semana!

日本語

最初のアウトランベータ版を発表できることを誇りに思います。このシステムは、2 つのゲーム (アウトラン とターボアウトラン) しかサポートしていませんが、通常よりも少し繁雑です。このボードには、共通メモリを共有する 2 つの M68000 CPU と、System 16B タイル マッパーと組み合わせた 2 つのロードレイヤーがあります。その上、非常に強力なスプライト処理ユニットもあります。これらすべてが、このハードウェアを当時の虜にしています。

今日のベータ版は最終版ではありません。元のスプライト ハードウェアは、フレーム バッファーを使用して、前の画像が画面にダンプされている間、すべてのスプライトをメモリ バッファーに描画していました。これは、他のほとんどすべてのアーケード ゲームで見られる一般的なライン バッファーよりもはるかにコストがかかります。ライン バッファーは、現在のイメージが別のメモリから画面にダンプされている間に、次のイメージをメモリに描画するという原則にも基づいて動作します。ただし、ライン バッファには 1 ライン分のメモリしかありませんが、フレーム バッファにはフレーム全体 (通常は 256 ライン) 分のメモリがあります。これにより、フレーム バッファのコストが大幅に高くなります。また、フレーム バッファによってスプライトに 1 フレームの遅延が発生するため、これを考慮してゲーム ロジックを設計する必要があります。

フレーム バッファは、1 行に描画するスプライトの量が回路で処理できる量を超える場合に必要でした。一般的なケースは、スプライトを使用して背景画像を描画できるゲームです。たとえば、Out Run でズーム効果を示す要素はすべてスプライトです。これには、道路周辺のすべてが含まれます (木々、海の波、風車、道路標識など)。

回路ロジックを非常に高速で動作させることができれば、フレーム バッファがなくても問題を解決できます。これは、ボード要件を軽減するため、最新の FPGA システムに推奨されるソリューションです。私はこれを CPS2 用に行ったので、MiST ファミリーのような小規模なシステムで動作します。しかし、『アウトラン』はうまくいきませんでした。ビデオを 100MHz で処理しても、すべてのスプライトが解析される前にライン タイムが終了し、画像のラインが欠落するほど雑然としたシーンがいくつかあります。

また、100MHz は FPGA にとって挑戦的な速度であるため、システム内で多くのタイミング違反が発生し始めます。デジタル回路のタイミング違反は、状況によっては信号の到着が遅すぎたり、信号の消失が早すぎたりして、情報が失われる可能性があることを意味します。全体として、高速クロックでのライン バッファー ソリューションは、FPGA でのアウトランのソリューションではありません。実際のフレーム バッファが必要です。

今日のベータ版は、ライン バッファ アプローチを使用して動作しますが、私はフレーム バッファ アプローチに取り組んでいます。フレーム バッファは、MiSTer および Pocket FPGA でのみ可能です。 MiST ファミリーには、それを保存するための二次 RAM がありません。 NeptUNOファミリーには1つありますが、そのシステムの実装は、ユーザー数が少ないため優先度が低くなります。（申し訳ありません）

スーパーハングオンコアの名前が JTSHANON に変更されたことに注意してください。以前はJTOUTRUNでした。これは、アウトランとスーパーハングオンのハードウェアの違いによるものです。後者にはスプライト フレーム バッファがなく、上記の問題に悩まされることはありません。このシステムでもいくつかの問題が修正されているため、今月の公開リリースに適しています。

他のニュースとしては、今日、ポケットFPGA用のビジランテが登場します。したがって、ポケットFPGA用のは、アウト ラン、ビジランテの 2 つのゲームを受け取ります。 ビジランテ は以前に他の FPGA システムで既に利用可能だったので、追いついたところです。

私の技術的な大言壮語を読んでくれてありがとう。また来週ね！