Flashback Is Finally Heading to Atari ST in a Work-in-Progress REminiscence Port

Flashback may finally be getting the Atari ST version that never arrived in its original era. Neil Rackett is working on a port of REminiscence, Gregory Montoir’s modern re-implementation of the original game engine, configured with STDL and Amiga data files. The project is explicitly a work in progress, but its goals are unusually concrete: a playable version of Delphine Software’s 1992 cinematic platformer on Atari ST hardware, with performance and presentation choices shaped around the machine’s limits.

That makes this more than a simple curiosity for retro-computing enthusiasts. Flashback is closely associated with the cinematic-platformer style: animation-led movement, staged action, environmental danger and a deliberately film-like sense of pacing. Its absence from the Atari ST lineup left an obvious historical gap for fans of the system. Rackett’s effort does not rewrite that history, but it provides a technically minded path to experiencing the game on the hardware that missed it.

A modern engine re-implementation, adapted for vintage hardware

REminiscence is not described as an original 1992 Atari ST conversion. It is a modern re-implementation of the original game engine, and Rackett has ported that project with STDL and Amiga data files. That distinction matters. A re-implementation is software rebuilt to reproduce the behavior of an existing engine or game rather than the original commercial program itself being directly transplanted.

For players, the meaningful outcome is the prospect of Flashback-style gameplay running on an Atari ST. For preservation-minded users, the method also illustrates a recurring route by which older systems receive software they did not get during their commercial lifetime: contemporary coding work is fitted around legacy hardware, while data from an existing version supplies the content the engine needs.

The port’s current status should remain front and center. It is not presented as a finished, fully polished release, and the developer is inviting testing, feedback and pull requests. A pull request is a proposed code change submitted through a collaborative development workflow; in practical terms, it gives technically capable community members a way to suggest fixes or improvements for the project. Users are also being asked to read the supplied README configuration material before reporting their findings.

Performance targets: 25fps on ST and STE, up to 30fps on Mega STE

The technical target is a consistent 25 frames per second on standard ST and STE systems. Frame rate, usually shortened to fps, measures how many individual screen images are shown each second. A stable rate can be particularly important to a cinematic platformer, where animations communicate when a character is running, stopping, climbing, drawing a weapon or recovering from a jump.

On a Mega STE, the project can run at up to a capped 30fps. The word capped is important: this is a stated upper limit rather than a promise that every moment will necessarily exceed the standard machines’ rate. Still, it offers Mega STE owners a configuration-specific benefit while preserving a defined performance target for ST and STE hardware.

A consistent 25fps is a practical design choice rather than an empty benchmark. The supplied details indicate that the port is being optimized around predictable animation timing on standard systems, not simply pursuing the highest number possible. That is relevant because the identity of a game like Flashback is tied to motion as much as to individual static screens. If the character animation and game response maintain an even rhythm, the presentation has a better chance of retaining the intended deliberate feel.

Fitting a 224-pixel game into a 200-pixel screen

The Atari ST’s display constraints are one of the central challenges addressed by the port. The original game uses a 224-pixel height, while a standard ST screen is 200 pixels high. Instead of treating that mismatch as an unavoidable deal-breaker, Rackett has included several menu choices: Fit, Fill and an experimental Overscan mode.

These names signal that there is no single perfect answer to the resolution problem. A fit-oriented setting generally prioritizes getting the full image within the available visible area. A fill-oriented setting instead suggests a preference for occupying the screen area, potentially with a different visual compromise. Overscan refers to using display area beyond the conventional visible boundaries; here it is explicitly experimental, so users should not assume it is the universal best choice or equally suitable for every setup.

The inclusion of selectable display behavior is one of the port’s most useful practical touches. It acknowledges the simple arithmetic behind the issue—224 vertical pixels do not directly fit into 200—and gives users a say in how they would prefer to handle it. The project is not pretending the underlying limitation disappeared. It is exposing options to manage it.

That kind of transparency is valuable in retro development. Older hardware is often defined by trade-offs, and a port that makes those trade-offs configurable can be more useful than one that silently picks a single compromise. For testers, it also creates meaningful feedback to provide: whether a given setting is readable, visually comfortable, stable or appropriate for the hardware they own.

Cutscenes work, but pacing takes priority

Cinematic cutscenes are operational in the current build. However, frames are skipped by default so that their pacing remains correct. This is another compromise that favors timing over showing every possible image frame. A cutscene that advances at the right overall speed can preserve narrative rhythm even if its animation is not presented frame-for-frame.

The choice fits the broader theme of the port: work within the ST’s limitations without losing sight of what makes the game recognizable. The project’s stated aim is a smooth gameplay experience, and the cutscene behavior demonstrates that “smooth” does not necessarily mean displaying every visual detail unchanged. In constrained environments, maintaining the appropriate tempo can be the more important goal.

There are also known visual rough edges. Most memorably, the protagonist’s trousers can match the background color in the opening level. It is a conspicuous, almost comical flaw, but its acknowledgement is useful. Prospective testers know they are entering an active development project, not evaluating a final build that claims to have every visual issue resolved.

What Atari owners need to know before testing

The minimum stated requirement is an Atari ST with at least 2MB of RAM. RAM, or random-access memory, is the working memory used while software runs. The recommendation rises to 4MB of RAM and 3MB of hard-disk space for the best experience. The difference between a minimum requirement and a recommendation is significant: 2MB is presented as enough to run the game, while 4MB and hard-disk storage are the preferred conditions.

• Minimum: Atari ST with 2MB RAM.
• Recommended: 4MB RAM and 3MB of hard-disk space.
• Standard ST/STE target: consistent 25fps animation.
• Mega STE target: up to a 30fps cap.
• Sound effects: available only on STE models.
• Music: experimental YM chip support is included across configurations.

Audio is another area where the exact model matters. Standard sound effects are reserved for STE systems because of hardware-specific constraints. Owners of a non-STE configuration should therefore not expect the same sound-effect behavior. Experimental YM chip music support is included for all configurations, though “experimental” again signals that users should treat it as an evolving part of the port rather than a final guarantee.

The YM chip is a sound chip associated with these Atari configurations. In this project, its significance is straightforward: it provides a route for music support even where the standard sound-effect arrangement is limited by the machine in use. The result is not an all-or-nothing audio picture. Sound capabilities vary by model, while music support is being explored more broadly.

Why community testing matters here

Rackett is not offering technical support, so this is best approached as a community-facing test build rather than a consumer product with conventional troubleshooting. Atari ST setups can vary in memory, storage and model type, and the project itself has display modes, performance differences and audio behavior that depend on configuration. Careful feedback is therefore more helpful than an assumption that every system should behave identically.

A useful test report would focus on reproducible details: the Atari model, installed RAM, whether a hard disk is in use, selected display mode, and what happens when an issue occurs. That is not a promise of individual support, but it is the type of information that can help an open development effort isolate a problem. The README configuration files are the starting point for users deciding how to set up the port.

For a broader look at the way new software continues to stretch classic platforms, see YokoXevi’s MSXdev26 ambitions. The circumstances differ, but the shared appeal is clear: old machines remain active technical targets when developers are willing to work creatively within their constraints.

An overdue Atari ST experiment, with honest limitations

The attraction of this project is not that it claims to erase every difference between systems. Its appeal is the opposite: it confronts the Atari ST’s particular constraints directly. There are modes for the vertical-resolution mismatch, fixed performance targets for different models, selective audio support and frame-skipping cutscenes intended to retain pacing. Those decisions reveal a port built around real hardware rather than an abstract idea of retro compatibility.

For Atari ST fans, the prospect is especially satisfying because Flashback skipped the platform when it mattered commercially. More than three decades later, the game is being approached through a new engine implementation and a testing-driven process. It remains unfinished, visual issues remain, and configuration will matter. But the work has already established a credible technical outline for bringing one of the era’s most recognizable cinematic platformers to a machine that never received it.