Technical Manual

Chapter 01

About Ultra Loader

What Ultra Loader is, what it runs, its overall purpose, and the concept of native execution.

Ultra Loader is, at its core, a native launcher for modern arcade games. This is a very important distinction. Ultra Loader was not built to emulate in the standard emulator sense. It was built to run modern arcade games in their native environment, as if they were built for the machine, in a clean and optimized setting, as if sitting in their original home cabinet. This distinction alone separates Ultra Loader from mostly everything that has come before it.

Launchers like TeknoParrot devise mechanisms to play many of these games at the surface level, giving the game what it needs to run through modified profiles and tactics that mostly do work, but Ultra Loader's premise is not to do this. The loader does things the hard way. To get some of these modern arcade games to run, the gap had to be bridged function by function, all to keep to the concept of native arcade execution.

At the bare minimum, Ultra Loader takes a game written for a specific arcade board, Taito Type X, Sega Lindbergh, Namco ES3, and so on, and gets it running on an ordinary PC, supplying the pieces of the cabinet that are missing: the I/O board, the coin mechanism, the dongle or key chip, the display mode, and the controls.

What is not easy is the concept of native emulation for games not designed for ordinary PCs. Sega Lindbergh was built to run in Linux, and getting it to run properly in Windows has been a long standing challenge. Natively executing Linux ELFs in Windows is no simple task, but it has been done, through a lot of painstaking work over many nights. This was also the key to unlocking other games that run only on Linux. Thus it was possible to keep to the original premise of native execution, even for boards that do not work natively in Windows or on common PC hardware. Prior to this, all that existed were pseudo hacks and compatibility layers. Now all that is needed is time and community dev work on fine tuning per game code in the board modules.

Ultra Loader also handles the concept that some games need special bypasses to make them believe they are talking to their parent servers that unfortunately no longer exist. The accompanying software had to be studied, reverse engineered, and code inserted to make the game behave as if it is still connected. The common term for this is "spoofing."

For the PC based arcade boards, many of the games are normal Windows executables, and Ultra Loader runs them directly, injecting a small hook that stands in for the hardware the game expects to find. This is, for all intents and purposes, Native Execution. For older non PC based boards, it hosts a core instead, but both paths are driven from the same window and the same settings.

The amazing work of predecessors like the folks who developed JConfig and the many devs on Emuline and other sites has been invaluable to the community. While Ultra Loader did not take from JConfig or any other source (all firmware modules were built from scratch), it is because of their separate work that this project had the confidence to begin. It is truly time for a brand new day.

Chapter 02

Ultra Loader's Three Mechanisms

The three interlocking pieces that make every game run.

The Ultra "Omni" Input Services

There are five "Omni" services that run inside the loader and publish a single, shared picture of what the player is doing. Every game's hook reads from that same shared block, which is why one controller setup applies everywhere rather than having to be repeated per game. This is the solution to per game setups.

Each service comes with a smart auto calibration setup that handles mostly all controllers, gamepads, and other HID compliant USB or Bluetooth gameplay devices, built specifically to help users simply get into the game and play. No more complicated setups. No more annoying workarounds for controllers, racing wheels, or lightguns. Mostly all hardware will be recognized and will work, even clone controllers.

Chapter 03

Installation and Folder Layout

Where everything lives in the main folder and on the backend.

Chapter 04

Quick Start

Getting one game running, and knowing whether it worked.

1. Browse to your game collection and select a game. Use the game selector in the main window and choose the actual game executable (game.exe), not a launcher bat script or a shortcut. Make sure the matching Ultra Firmware files are copied into the firmware folder.
2. Let it identify the board. Ultra Loader reads the path and the executable from the firmware to decide which board the game belongs to, and says so in the log as [PREFLIGHT]. It can never guess wrong, as the firmware file contains the game's board information. This is done in the background.
3. Check or modify your display settings. Most arcade games were written for a fixed resolution. See Chapter 6 for what the game upscaler does, and when to leave it alone for best results.
4. Launch the game. The Ultra Loader blue init screen appears first, then the game's boot console, then the game should load.

Reading the Log

When a game does not behave, ultra.log answers most questions on its own. These are the lines worth knowing:

Chapter 05

The Main UI Window

Choosing a game, and the main window buttons.

Chapter 06

Display and Rendering Options

Resolution, upscaling, frame pacing and the screen itself. Every control in the DISPLAY section.

Arcade games are fixed resolution in a way PC games are not: many ask for exactly 640x480 and will not negotiate. To render fullscreen or at a higher resolution, the games must be forced. The options here work specifically for that, either by asking the game for a larger buffer where it can cope, or by stretching what it produces to fill your screen.

Boot Mode Reference

* If both are off and no game has ever been run, the loader overrides and shows the menu until a game is selected or Cabinet Mode is ticked.

Chapter 07

Audio Settings

The AUDIO section. Simple, straightforward, cool, and normal.

Chapter 08

Game Settings

Per title behavior: free play, language, attract mode and save states.

Chapter 09

Controllers and Firmware

Why the controls were designed this way, and what per game Ultra Firmware (.ufw) does.

For Ultra Loader, there are three distinct device software layers that decide what happens when you press a button, and each owns its own role. The Omni input services in the loader decide which devices exist, how they present, and what state they are in. That work is the same for every game and every board, which is why it lives in the loader and is configured universally.

Each game possesses a custom built firmware "profile" or container. That container decides what each control means on that game's cabinet: which JVS switch bit a button drives, which analog channel a pedal feeds, and the calibration window the game's own saved settings expect. That map travels inside the signed, protected firmware container, so it belongs to that game alone and no other game can see it.

The actual system board module is the translator between the two. It takes the container's map and renders it onto the JVS wire the game reads. Where the container has an opinion, the container always wins, and this governs the whole input sequence.

The reason this approach was necessary: one game reads its buttons at the JVS positions that normal convention expects, and the next one puts START on the eighth switch and VIEW on the seventh, with steering on analog channel two rather than channel zero. This is exactly what causes all the problems in other launchers. Trying to build a universal hook that satisfies every game ends up satisfying none of them. Controls fail, setups break, and it becomes the same hot mess of game by game workarounds the community has already endured for years. The only clean answer is to ship what each game wants for itself, inside its own firmware, so that every game is right about itself and no other game is affected.

In addition, no dump ever gets written to, ever. The arcade dump must stay clean, and all contents and areas for modification are read from a cache provided by the game's own custom firmware. This also ensures that two titles on the same board can never conflict over controls. All games coexist within the loader, each one taking only from what the Omni services provide for it.

Firmware Container Structure

Each game firmware package comes in the form of a top and bottom layer. The bottom layer is read only and boots the game. The top layer is the play/tinker/dev area, enabled only once per session in the loader and never graduated to the bottom layer. Once dev improvements are made, all firmware packages need to be properly signed before the loader will accept them again. See Chapter 13 for more on the signing system.

Configure Controls Dialog

Chapter 10

The Omni Input Services (In Detail)

Gamepads, wheels, flight sticks, and lightguns, all configured once, applied to every game.

Each service has a master switch plus per slot settings. The per slot settings are the same for each slot; they are listed once per service below with the slot number written as N.

Ultra Omni Play (Gamepad)

Per slot settings (one row per slot): Enable slot · Brand/status · Dead zone % (0 50) · Response curve % (50 200) · Rumble on/off · Rumble test

Ultra Omni Steer (Flight Stick)

Per slot settings: Enable slot · Brand/status · Dead zone % · Sensitivity % · Response curve % · Invert X · Invert Y · Invert Z · Throttle reverse · FFB test

Ultra Omni Wheel (Racing Wheel)

Per slot settings: Enable slot · Dead zone % · Sensitivity % · Response curve % · Invert · Brand/status

Ultra Omni Track (Lightgun)

Per slot settings: Enable player slot · Assigned gun (Auto detect or specific brand profile)

Ultra Omni Bridge (Gamepad to Keyboard/Mouse)

Chapter 11

Credits and Coins

Free play, the on screen coin pill, and automatic coin and credit insertion.

Most arcade games expect a coin mechanism. Ultra Loader can supply one in three ways: by switching the game into its own free play mode, by giving you a coin button, or by inserting credits automatically when the game boots.

Hotkey & Base Coin

Auto Insert on Game Boot

On Screen Coin Pill

Chapter 12

Boards and Systems

Every arcade board Ultra Loader supports, and what each one needs.

Ultra Loader identifies the board from the game's path and executable, then loads the matching firmware container. Board keywords are matched against the game's path, using the longest and most specific name first. The loader also recognizes games by the firmware container's internal header, so even if you label a game wrong, it will still find it. That said, label your game folders accurately so that your art/icons display correctly.

Chapter 13

Firmware Signing and Protection

The most important chapter of this entire manual. Please read this to understand what was done and why.

Given the problem of gatekeeping and profiteering by certain individuals using these modern arcade games against the community, along with the development potential of this software, it became clear that some form of protection was needed against this happening again. This was not merely to prevent gatekeeping and profiteering, but also very importantly, to protect the community.

Malware exists, and many ill intentioned people use it constantly. The types of software that launch arcade games usually live on the edge of what most operating systems would report as exploits and viruses. With the rise of AI and other tools available to bad actors, the risk is ever more prevalent. As such, a firmware signing system was developed for all games, permanently locked against the loader.

Every game's firmware is signed, and the loader verifies that signature before it will load the game. The check is fully enforced. Any module that has been edited or tampered with, even in the slightest way, will be refused, and the log will show a [SIGCHECK] error with the reason.

The per-board system modules are source available: anyone can read, build, and improve them, and every improvement raises compatibility for all games on that board. The per-game firmware is closed source and is distributed only through the loader, released when a game is confirmed working; you can still tune a game through its unsigned top layer while the signed core stays locked. A rebuilt module must be re signed before it will load a game again, which prevents random, unsigned modules from being loaded.

Chapter 14

Ultra.ini Reference (The Settings File)

Every key the loader reads and writes, in the order it stores them.

Settings are saved to ultra.ini beside the loader. You can edit it by hand while the loader is closed. It is rewritten atomically on save, so a crash cannot leave a half written file.

Chapter 15

Environment Variables (For the Devs)

Overriding any setting from outside, for scripting and for testing.

Every setting reaches the game as an environment variable, and an explicit variable set before launch wins over both the saved settings and any board default. This is the supported way to script the loader or to test one change without disturbing your configuration.

The loader itself publishes or reads the 150+ variables below. Individual board hooks add many more. Those are documented in each board's own source code and are not user settings.

Chapter 16

Troubleshooting

The failures that come up the most, and what each one usually means.