Namco System FL for MiSTer — Speed Racer and Final Lap R

Supporter Edition - First Release - Download below.

With the September Supporter Poll now live and supporters actively voting on future development priorities, I wanted to share a little surprise I’ve been working on behind the scenes.

While the Namco System FL board is home to only two games, both are a lot of fun and hold some great memories for me. That made FL a project I was especially excited to take on and bring to MiSTer.

NEW BOARD. NEW CORE.

Namco System FL has arrived on MiSTer.

Released in 1995, System FL powered Speed Racer and Final Lap R. It is a sprite-scaling racing platform built around an Intel i960 RISC CPU, three Namco custom video processors - C123 tilemaps, C169 road generation, and C355 sprites — plus a C352 PCM sound system driven by a C75 sound MCU.

This first Supporter Edition brings both System FL games to real MiSTer hardware, with working graphics, controls, and sound — running at the correct game speed.

Getting here required solving two major problems:

1. Rendering every scanline reliably without graphics dropouts.

2. Getting the i960 implementation fast enough for the games to run at their intended speed.

Both are now solved.

WHAT'S INCLUDED — 2 GAMES, 5 VERSIONS

Speed Racer — 1995

Namco's arcade interpretation of the Mach 5, complete with:

• Jump button

• Three weapons

• Countdown clock

• Four rivals who definitely do not play fair

Final Lap R — 1995

The final entry in Namco's Final Lap series, running on considerably more advanced hardware and based around the 1992 Formula One season.

Four regional/revision sets are included:

• World Rev. B

• World

• Japan Rev. B

• Japan Rev. C

All .mra files are installed under:

Arcade/XelaNotPu/Namco System FL/

Every set uses the optimized fast-loading layout: a single contiguous ROM stream, allowing a roughly 22 MB System FL ROM set to load in seconds rather than close to a minute.

THE PICTURE — ZERO MISSED SCANLINES

System FL is extremely demanding on memory bandwidth.

During every scanline, the C169 road processor, C355 sprite processor, and C123 tilemap system may all need graphics ROM data at the same time — while the i960 CPU is also requesting program and data access from the same memory system.

On MiSTer, all of those requests ultimately compete for SDRAM bandwidth.

The early builds made that very obvious:

• Black bands through tilemaps

• Distant road lines disappearing or flickering during busy scenes

• Sprite peaks tearing

• Intermittent dropped graphics data

It took 15 hardware-validated builds to eliminate those problems.

The final architecture includes:

• A two-tier priority arbiter that gives video ROM fetches and audio priority over the CPU.

• A deadline-based urgency system between video clients, allowing the layer closest to missing its scanline deadline to run first.

• The SDRAM controller increased to 100 MHz — twice the core clock.

• A read-ahead block cache.

• 128-bit client reads, reducing what previously required eight transactions to a single transfer.

• Updated C169 road behavior based on MAME's recent C169 rewrite.

• A dedicated per-tile mask cache for the road processor.

• A 4× larger pixel cache for the sprite processor.

• Immediate object-RAM draining whenever the sprite write queue fills.

And finally, the change that eliminated the problem completely:

Road and sprite layers are now rendered one frame ahead into DDR3 framebuffers.

That removes the real-time scanline memory race entirely.

The road and sprite layers therefore trail the tilemap layer by exactly one frame. In normal motion I cannot see the difference, including during frame-by-frame testing.

The number that matters:

Across multi-minute attract-mode and gameplay tests of both games, the core now reports zero missed lines across every video layer.

Every frame displayed by the core is complete.

THE SPEED — THE COUNTDOWN CLOCK TELLS THE TRUTH

Speed Racer happens to include one of the best performance benchmarks you could ask for: an on-screen countdown timer.

One game second should equal one real-world second.

Once the graphics pipeline was finally stable, the timer revealed another problem.

The game was running approximately 13% too slowly in the later builds — and considerably slower in earlier versions.

It was playable, but everything was late:

• AI vehicle behavior

• Engine sounds

• Checkpoints

• Race events

• Countdown timing

The bottleneck was the i960 CPU implementation.

The existing i960 core used a relatively straightforward sequential architecture. Instruction fetches, data reads, subroutine calls, and returns frequently went all the way to SDRAM, where they then competed with the video hardware for memory bandwidth.

The solution was to make the CPU behave more like the real processor by keeping frequently accessed information close to the execution pipeline.

Three major additions were made.

Instruction Cache

Instruction-cache misses now load an entire block at once.

Branch displacement data can then be serviced directly from the cache instead of repeatedly accessing SDRAM.

Data Read Buffer

A one-block read buffer was added for data accesses.

System FL frequently performs sequential reads, so many of those accesses can now be satisfied locally.

i960 Register Frame Cache

This produced the biggest improvement.

The i960 calling convention saves and restores 16 registers during function calls and returns. The real processor keeps several register frames internally instead of constantly writing them to external memory.

The MiSTer implementation now does the same.

Four register frames can remain cached internally, with frames spilling to memory only when the call stack becomes deeper.

THE BUG THAT ONLY REAL HARDWARE FOUND

This change also produced one of the more interesting bugs of the entire project.

The register-frame cache passed every simulation test.

On the real MiSTer, however, the result was a black screen.

The CPU was still alive — JTAG showed that clearly — but it had become trapped inside the vertical-blank interrupt handler, repeatedly executing the same few dozen instructions.

The problem was an interaction none of the tests had exercised:

An interrupt handler that itself performs a function call.

Interrupt entry had saved the interrupted register frame to memory.

The interrupt handler then made another call, which pushed its own frame into the new register cache.

When the handler returned, it encountered the wrong frame at the top of the stack, flushed the cache, and restored only one of the sixteen registers belonging to the interrupted code.

Unfortunately, the interrupt return address lived in one of the other fifteen.

The fix ultimately required only two lines of logic.

A new regression test now reproduces the problem on the old implementation and passes with the corrected one.

With that fix in place, the real board immediately came back to life.

THE RESULT — REAL TIME

The final test was simple.

Run the exact bitstream included in this release.

Start a stopwatch.

Watch Speed Racer's countdown clock.

23 game seconds = 23 real seconds.

System FL is now running in real time.

Speed Racer finally plays at the pace it was designed for.

SUPPORTER FEATURES — ALL PRESENT

As with the System 11 and System 22 Supporter Editions, the underlying arcade hardware implementation remains the core itself, while the Supporter Edition includes additional cabinet-oriented features that do not fit within the public distribution requirements.

DB9 / DB15 Joystick Support

Support is included through an Antonio Villena user-port splitter.

Available OSD modes:

• Off

• Saturn

• DB9 MD

• DB15

OSD navigation directly from the joystick requires the MiSTer-DB9 firmware.

Because this uses the eighth user-port line, the uncommon secondary SPI-SD configuration remains unsupported.

CRT Adjust

Live CRT geometry controls are available directly from the OSD:

• H-Size

• H-Position

• V-Shift

Native synchronization is preserved.

Default: Off

Credit to rmonic79 and Andrea Bogazzi's MiSTer-CRT-Adjust project.

Pause Support

A proper Pause control is included and can be mapped through the MiSTer OSD.

It appears as the final button in the mapping list.

Keyboard users can also press:

P

Pausing displays the Supporter credits screen, refreshed with the current supporter list:

• Gold — Hall of Fame

• Cyan — High Score

• Green — Insert Coin

If your name is there, you are seeing it rendered on the actual FPGA hardware.

The previous menu-based pause behavior remains available through:

Pause when OSD is open

Default: Off

CONTROLS AND CABINET NOTES

Speed Racer

Controls include:

• Accelerator

• Start / Jump

• Weapon 1

• Weapon 2

• Weapon 3

• Coin

• Service

• Test

• Pause

One important note:

Speed Racer defaults to three credits per play.

That is the game's factory configuration, so insert three credits before trying to start a race.

Final Lap R

Controls include:

• Accelerator

• Brake

• Shifter

• Coin

• Service

• Test

• Pause

Steering can be controlled through:

• Joystick

• Analog axis

• Paddle

The active steering mode is selectable through the OSD.

Acceleration can likewise use either:

• Digital button

• Analog axis

So yes — a proper steering wheel works exactly the way you would expect.

FINAL LAP R NVRAM

Final Lap R is configured to be playable immediately after installation.

The .mra seeds the board with factory NVRAM data, preventing a fresh installation from dropping directly into an unconfigured service menu.

Once you modify settings or save a record, your own .nvm file takes over.

The Freeze Screen DIP option is also exposed because it exists on the original hardware.

A FEW IMPORTANT NOTES

FPGA Usage

The FPGA is currently approximately:

97% full

All clocks close timing successfully, but there is very little space remaining.

Future features will therefore need to justify every resource they consume.

One-Frame Road/Sprite Pipeline

As explained above, the road and sprite layers are rendered one frame ahead of the tilemaps.

I have not been able to see the difference during gameplay or frame-by-frame inspection.

If you find a situation where it becomes visible, let me know exactly where.

Final Lap R Regional ROMs

Regional versions of Final Lap R require SPLIT clone ZIPs in:

games/mame/

A merged finalapr.zip provides only the parent set.

Native Video Output

There are no 480i tricks and no rotation involved.

System FL's native output is:

288 × 224 progressive

That is what the core outputs.

INSTALLATION

1. Copy the release's Arcade directory onto your MiSTer SD card's existing Arcade directory.

The core installs as:

Arcade/cores/Arcade-XNSYSTEMFL20260923.rbf

The .mra files install under:

Arcade/XelaNotPu/Namco System FL/

Browse to _XelaNotPu in the MiSTer Arcade menu to launch them.

The .mra files reference the core as:

XNSYSTEMFL

1. Supply your own ROM ZIPs under:

games/mame/

Required sets include:

speedrcr.zip

finalapr.zip

Plus the appropriate split clone ZIPs for the additional Final Lap R regional versions.

No ROMs are included with this release, and none ever will be.

BUILD INFORMATION

Build MD5

b9ac2aaffabdfd457ab06ab9e8c48a86

SHA256SUMS is included and covers every file in the release.

The core is released under the GPL, and the complete corresponding source for this exact bitstream is available.

CREDITS

A lot of existing work helped make this possible.

Special thanks to:

The MAME Team
The System FL driver and recent C169 road implementation provided essential technical reference material throughout development.

rmonic79 & Andrea Bogazzi
MiSTer-CRT-Adjust.

MiSTer-DB9 Project

• Aitor Pelaez / NeuroRulez

• Victor Trucco

• Fernando Mosquera

• Timothy Redaelli

Antonio Villena
For the user-port splitter hardware.

And as always, thank you to everyone supporting the work.

Two more Namco racers are now on the MiSTer shelf.

Correct speed. Every scanline present. Real hardware.

Go beat the clock.

DISCLAIMER
Legal Notice, License & Third-Party Attribution

Project: Namco System FL for MiSTer (XelaNotPu)
Release: RELEASE-PATREON-SYSTEMFL-20260923 (Supporter Edition)
Core: Arcade/cores/Arcade-XNSYSTEMFL20260923.rbf
Primary license: GNU General Public License, version 3 or later (GPL-3.0-or-later)
License texts: COPYING.GPL3; GPL-2.0-or-later components are covered by COPYING.GPL2

This notice summarizes the copyright, licensing, attribution, and legal information
for this release. It supplements, and does not replace, the license texts,
copyright notices, source-file headers, or README.md included with the release.
If this notice conflicts with an applicable software license or a source-file
copyright/license notice, the applicable license and source-file notice control.

1. Copyright and Software License

This core is free software. The combined release is distributed under the
GNU General Public License, version 3 or later (GPL-3.0-or-later).

The source tree contains components originally made available under
GPL-2.0-or-later as well as components made available under GPL-3.0-or-later.
GPL-2.0-or-later code may be used under GPLv3 when combined with
GPL-3.0-or-later code. Individual third-party files retain the copyright notices
and license options stated in their own headers or upstream projects; this notice
does not relicense those files independently of their existing terms.

Subject to the applicable GPL terms, recipients may use, study, modify, copy,
and redistribute the covered software. Distribution of a compiled FPGA
bitstream does not remove the corresponding source-code obligations imposed by
the applicable GPL terms.

The full texts of the relevant GPL versions accompany this release.

2. Third-Party Components and Attribution

This project incorporates, adapts, or builds upon open-source work from other
projects. Each imported component retains its original copyright and license
notices.

Component / referenceAttributionLicense / statusMiSTer framework and sys/ infrastructureMiSTer-devel, Alexey Melnikov (Sorgelig), Till Harbaum, and contributorsLicense varies by file/upstream source; MiSTer framework files commonly carry GPL-2.0-or-later or GPL-3.0-or-later notices. Consult the imported file headers.DB9 / DB15 / Saturn user-port controller supportMiSTer-DB9 ecosystem; work includes contributions by Aitor Pelaez (NeuroRulez), Victor Trucco, Fernando Mosquera, Timothy Redaelli, and others; splitter hardware associated with Antonio VillenaConsult the exact imported source-file headers and upstream repository notices.CRT AdjustUmberto Parisi (rmonic79), with acknowledged contributions from Andrea Bogazzi (asturur)GPL-3.0-or-laterM37702/C75 and C352-related FPGA logic reused from this project's Namco System 11 workXelaNotPuConsult the originating source-file headers; retained under their applicable GPL terms.Pause / credits overlay logic reused from this project's Namco System 12 workXelaNotPuConsult the originating source-file headers; retained under its applicable GPL terms.Namco System FL hardware and behavioral referenceMAME project, especially src/mame/namco/namcofl.cpp by R. Belmont and ElSemi, plus shared Namco device implementations and contributorsThe current namcofl.cpp source file is BSD-3-Clause. It is used as technical documentation and a behavioral reference; MAME source code is not incorporated into this FPGA implementation.

MAME is used as a hardware-documentation and behavioral reference. This project
does not redistribute the MAME source tree as part of the core release, and no
MAME emulator source code is intended to be incorporated into the FPGA bitstream.

3. No Game ROMs or Original Game Assets

This release does not include game ROM images, the original C75 program ROM,
factory/default game NVRAM images, or original game graphics, audio, video, or
other copyrighted game assets.

The included .mra definitions identify the ROM sets and ROM components required
to operate the supported software. They do not contain the game ROM payloads
themselves.

For the currently documented MAME System FL sets, the relevant set names are:

• speedrcr

• finalapr

• finalapr1

• finalaprj

• finalaprj1

Required ROM, firmware, and NVRAM data must be supplied separately by the user.
Users are responsible for ensuring that their possession, copying, dumping,
storage, and use of such data is lawful in their jurisdiction.

Game software and the audiovisual works contained in it remain the property of
their respective rights holders. The GPL covering this FPGA project grants no
rights to third-party game software or game assets.

4. Independent Hardware Re-Implementation

The FPGA logic in this project is an independent re-implementation of the
behavior of the Namco System FL arcade platform.

Development uses publicly available technical information, observable hardware
behavior, and publicly available emulator documentation as engineering
references. In particular, MAME's System FL driver and shared Namco device
implementations are used to understand documented memory maps, device behavior,
timing, and board organization.

The project does not claim ownership of the original Namco hardware design or
the software created for that hardware. The HDL implementation is intended to
reproduce externally observable hardware behavior for interoperability and
preservation purposes, not to reproduce proprietary manufacturer source code,
netlists, or game ROM contents.

The i960KA-compatible FPGA implementation used by this project is intended as an
independently written HDL implementation based on publicly documented processor
behavior and architecture; it is not an Intel RTL or netlist implementation.

5. Supported Namco System FL Software

The current MAME System FL driver documents two game titles represented by five
ROM sets:

MAME setMAME descriptionYearspeedrcrSpeed Racer1995finalaprFinal Lap R (Rev. B)1994finalapr1Final Lap R1994finalaprjFinal Lap R (Japan Rev. C)1994finalaprj1Final Lap R (Japan Rev. B)1994

MAME notes that Final Lap R was released in February 1994 while displaying a
1993 copyright date on its title screen.

This release is intended to interoperate with the System FL software listed
above. None of that game software is included with this project.

6. Trademarks and Non-Affiliation

Names, logos, characters, product names, company names, hardware names, and
other marks referenced by this project may be trademarks, registered trademarks,
or copyrighted works of their respective owners.

This includes, where applicable, names associated with Namco / Bandai Namco,
Speed Racer, Mach 5, Final Lap R, Intel, i960, Formula One, F1, FIA, MiSTer,
and other third parties whose products or works are identified for compatibility
or historical documentation.

This project is independent and is not affiliated with, authorized by,
endorsed by, sponsored by, or officially connected with Bandai Namco
Entertainment, Speed Racer rights holders, Tatsunoko Production, Intel,
Formula One entities, the FIA, MiSTer-devel, MAMEdev, or any other third-party
rights holder or project unless expressly stated otherwise.

Third-party names and marks are used only as reasonably necessary to identify
hardware, software, compatibility, provenance, or technical references. No
ownership, sponsorship, or endorsement is claimed or implied.

7. Purpose and Distribution

This is an independent hardware-preservation, interoperability, research, and
educational project intended to document and reproduce the behavior of legacy
arcade hardware so that compatible, lawfully possessed software can continue to
be studied and used.

Supporter access through Patreon helps fund development and testing. Charging a
fee for access to or distribution of GPL-covered software does not reduce or
remove the rights granted to recipients by the GPL. Recipients retain the rights
provided by the applicable GPL terms, including the right to redistribute the
covered software subject to those terms.

No Patreon payment, download, or copy of this core grants any license to
third-party game ROMs, artwork, music, characters, trademarks, or other
proprietary game content.

8. Security / Key Hardware and Technological Protection Measures

The current MAME System FL PCB documentation identifies a KEYCUS2 position at
location 13D and specifically records it as not populated on the documented
System FL board.

Accordingly, this core does not implement a System FL KEYCUS security device or
a key-chip bypass. It implements the hardware behavior required by the supported
software and loads required user-supplied program/data ROM content at runtime.

This section is a technical description of the implementation, not a legal
opinion about anti-circumvention law. Laws concerning technological protection
measures, including 17 U.S.C. § 1201 and analogous laws in other jurisdictions,
may vary by jurisdiction and by use case. Users are responsible for their own
legal compliance.

9. User Responsibility

Users are solely responsible for ensuring that their use of this core, including
their acquisition, copying, dumping, storage, modification, and use of any ROM,
firmware, or NVRAM data, complies with applicable law.

The authors and contributors make no representation that any particular use of
third-party software or data is lawful in every jurisdiction or circumstance.

10. No Warranty and Limitation of Liability

This software is provided subject to the warranty disclaimer and limitation of
liability contained in the applicable GNU General Public License terms,
including GPLv3 Sections 15 and 16 and the corresponding provisions of GPLv2 for
files used under that version.

To the maximum extent permitted by applicable law, the software is provided
without warranty, and users assume the risks associated with installing,
configuring, modifying, or operating it.

Use with external hardware, including CRT displays, analog-video equipment,
user-port controller adapters, DB9/DB15 interfaces, and other connected devices,
is at the user's own risk. Incorrect configuration or incompatible hardware may
cause malfunction or equipment damage.

Consult COPYING.GPL2 and COPYING.GPL3 for the controlling license text.

11. Corresponding Source and Build Identification

The GPL requires distributors of covered object code, including FPGA bitstreams,
to provide or make available the applicable Complete Corresponding Source in
a manner permitted by the governing GPL version.

For network distribution under GPLv3, equivalent access to the Corresponding
Source should be provided with access to the object code at no additional
charge, as described in GPLv3 Section 6. GPLv2-covered components remain subject
to the source-distribution requirements of GPLv2.

Release metadata for this build records:

• Bitstream: Arcade/cores/Arcade-XNSYSTEMFL20260923.rbf

• Build MD5: b9ac2aaffabdfd457ab06ab9e8c48a86

• Source commit: 2cabe98

The Corresponding Source supplied or made available for this release should
match the bitstream identified above, including the source files and build
scripts required by the applicable GPL definition of source code.

This notice is provided to document the project's licensing, attribution, and
distribution posture. It is not legal advice. Rights, exceptions, and compliance
requirements can vary by jurisdiction and by the facts of a particular use or
distribution. If legal advice is required, consult qualified counsel in the
relevant jurisdiction.

Source: Github