Out Run Update

(Español abajo, 日本語は以下)

The last time we talked about Out Run, we had the game running on several platforms with the FPGA clocked at 96MHz and some graphic glitches, especially in the sprites. The 96MHz version wasn’t stable on MiSTer and it didn’t work for many people. A 48MHz version was available too, which was stable but more glitchy. What makes Out Run so challenging to convert to FPGA?

The problem is that although the devices on Out Run board operate around 12MHz, there is a large number of them working at the same time. There are six different subsystems accessing video data continuously (two scroll, one fixed one sprite and two road layers), plus three CPUs. The game also draws so many sprites and so large that there is not enough time to draw all them on a line basis (even using a 96MHz clock). The original board used a frame buffer to draw the sprites there 1-frame ahead of time and then dump them in the next frame. The frame buffer requires 512kB of memory. The same as the whole memory of an Amiga 500.

Overall, the memory bandwidth (speed) required by this game makes it impossible to have everything running off a single SDRAM chip. The frame buffer sections has to be taken out of the SDRAM. That requires a second external memory chip. The MiSTer has a DDR chip -shared with the linux subsystem- and the Pocket has two CRAM chips.

For the Pocket, the CRAM functionality is clearly described by the manufacturer and the FPGA-CRAM connection is direct. Thus, adding a sprite frame buffer on the Pocket took about a week.

For the MiSTer, the situation is more complex. The DDR memory is not connected directly to the FPGA fabric and is shared with the linux subsystem. That means that latency is unpredictable. I don’t know how much speed I can get it from it. We know it’s enough to work as a frame buffer on vertical games, so it should be enough for sprite frame buffer in Out Run. Another problem is that the DDR interface goes through some MiSTer framework files and eventually into some Intel proprietary modules. This makes the interface obscure in terms of documentation and very difficult to include in a simulation. So all trials have to go through a lengthy 10+ minute compilation and require a MiSTer power cycle, which makes the development process slow.

Taking the clock speed down to 48MHz has rendered glitches in the road layers. So there is some extra work needed to move the road ROM memories inside the FPGA so the SDRAM is less busy. Overall, I think Out Run still needs one week to fix most problems. I think we should be able to make a public release on the 24th of March only for Pocket and MiSTer devices.

On other news: work on the Konami CPU continued normally and we started tracing the first CPS3 custom chip yesterday. There will be no Friday update next week but we maintain the target of the 24th of March for Konami CPU completion.

Español

La última vez que hablamos de Out Run, teníamos el juego ejecutándose en varias plataformas con el FPGA sincronizado a 96 MHz y algunos fallos gráficos, especialmente en los sprites. La versión de 96 MHz no era estable en MiSTer y no funcionó para muchas personas. También estaba disponible una versión de 48MHz, que era estable pero con más fallas. ¿Qué hace que Out Run sea tan difícil de convertir a FPGA?

El problema es que, aunque los dispositivos de la placa Out Run funcionan en torno a los 12 MHz, hay un gran número de ellos funcionando al mismo tiempo. Hay seis subsistemas diferentes que acceden a los datos de video de forma continua (dos de scroll, uno de carácteres, uno de sprites y dos capas de carretera), más tres CPUs. El juego también dibuja tantos sprites y tan grandes que no hay tiempo suficiente para dibujarlos todos al vuelo (incluso usando un reloj de 96 MHz). La placa original usaba un búfer de frame para dibujar los sprites con 1 fotograma de antelación y luego los volcaba en el siguiente fotograma. El búfer requiere la friolera de 512 kB de memoria, todo lo que tenía un Atari ST de la época.

En general, el ancho de banda de la memoria (velocidad) que requiere este juego hace que sea imposible que todo funcione con un solo chip SDRAM. Las secciones del búfer deben sacarse de la SDRAM. Eso requiere un segundo chip de memoria externo. El MiSTer tiene un chip DDR -compartido con el subsistema linux- y la Pocket tiene dos chips CRAM (y un minúsculo e inútil chip SRAM).

Para Pocket, la funcionalidad CRAM está claramente descrita por el fabricante y la conexión FPGA-CRAM es directa. Agregar un búfer para los sprites en Pocket llevó alrededor de una semana.

Para MiSTer, la situación es más compleja. La memoria DDR no está conectada directamente a la estructura FPGA y se comparte con el subsistema Linux. Eso significa que la latencia es impredecible. No sé a qué velocidad puedo llegar. Sabemos que es suficiente para funcionar como búfer de frame en juegos verticales, por lo que debería ser suficiente para el búfer de sprites en Out Run. Otro problema es que la interfaz DDR pasa por algunos archivos de la MiSTer y, finalmente, por algunos módulos propietarios de Intel. Esto hace que la interfaz sea oscura en términos de documentación y muy difícil de incluir en una simulación. Por lo tanto, todas las pruebas deben pasar por una larga compilación de más de 10 minutos y requieren un ciclo de encendido y apagado de la MiSTer, lo que hace que el proceso de desarrollo sea lento y tedioso.

Reducir la velocidad del reloj a 48 MHz ha generado fallas en las capas de la carretera. Por lo tanto, se necesita algo de trabajo adicional para mover las memorias ROM de carretera dentro de la FPGA. Así la SDRAM estará menos ocupada. En general, creo que Out Run necesitará una semana para solucionar la mayoría de los problemas. Espero poder hacer un lanzamiento público el 24 de marzo solo para dispositivos Pocket y MiSTer.

En otras noticias: el trabajo en la CPU de Konami continuó normalmente y ayer comenzamos a trazar el primer chip personalizado de la CPS3. No habrá actualización del viernes la próxima semana, pero mantenemos el objetivo del 24 de marzo para la finalización de la CPU de Konami.

日本語

前回のアウトランの話では、FPGAのクロックが96MHzで、特にスプライトのグラフィックに不具合がある状態で、複数のプラットフォームでゲームを動作させていました。96MHz版はMiSTerで安定せず、多くの人に通用しませんでした。48MHz版もあり、こちらは安定していましたが、より不具合が多かったです。アウトランをFPGAに変換するのが難しい理由は何でしょうか？

問題は、アウトランボードのデバイスは12MHz前後で動作していますが、同時に動作するデバイスが多いということです。ビデオデータに連続的にアクセスするサブシステムは6種類（スクロール2種類、固定1種類、スプライト1種類、道路レイヤー2種類）、さらにCPUは3種類あります。また、このゲームは非常に多くのスプライトを描画するため、ライン単位ですべてのスプライトを描画するには時間が足りません。（96MHzのクロックを使用しても）オリジナル基板では、フレームバッファを使って、そこに1フレーム先のスプライトを描画し、次のフレームでダンプしていました。このフレームバッファには512kBのメモリが必要です。Amiga500の全メモリと同じであります。

全体として、このゲームに必要なメモリ帯域（速度）は、すべてを1枚のSDRAMチップで動作させることは不可能であります。フレームバッファの部分は、SDRAMから取り出さなければなりません。そのためには、2つ目の外部メモリチップが必要です。MiSTerにはDDRチップ（Linuxサブシステムと共有）があり、PocketにはCRAMチップが2つあります。

Pocketの場合、CRAMの機能はメーカーによって明確に説明されており、FPGAとCRAMの接続は直接行われています。そのため、Pocketでスプライトフレームバッファを追加するのに1週間ほどかかりました。

MiSTerの場合、状況はより複雑です。DDRメモリはFPGAファブリックに直接接続されておらず、Linuxサブシステムと共有されています。つまり、レイテンシが予測不可能なのです。それでどれだけの速度が得られるかはわかりません。縦長のゲームではフレームバッファとして十分機能することがわかっているので、アウトランのスプライトフレームバッファとしては十分でしょう。もう1つの問題は、DDRインターフェイスがいくつかのMiSTerフレームワークファイルを経由して、最終的にいくつかのIntel独自モジュールに入ることです。このため、インターフェイスのドキュメントが曖昧で、シミュレーションに組み込むのが非常に難しいのです。そのため、すべてのトライアルは10分以上の長いコンパイルを経なければならず、MiSTerの電源サイクルを必要とするため、開発プロセスが遅くなってしまいます。

クロックスピードを48MHzまで落とすと、ロードレイヤーに不具合が発生します。そのため、FPGAの内部でロードROMのメモリを移動させ、SDRAMの使用頻度を下げるための追加作業が必要です。全体として、アウトランは、ほとんどの問題を解決するために、まだ1週間必要だと思います。3月24日には、ポケットとMiSTerのデバイスに限って公開できると思います。

その他のニュース：コナミ CPUの作業は通常通り行われ、昨日、最初のCPS3カスタムチップのトレースを開始しました。来週は、金曜日のアップデートはなく、コナミ CPUの完成は3月24日という目標を立てています。