Native OpenTTD port brings transport management to 68k Amigas

OpenTTD now runs natively on AmigaOS 3.x. That sounds simple. It isn’t. The new 68k port takes OpenTTD 1.0.5 and adapts it for AGA-equipped Amigas without relying on SDL or requiring an RTG graphics card. Instead, it talks directly to familiar Amiga system components, including Intuition, graphics.library and the machine’s planar display hardware. The current v0.4.1 build remains a work in progress, but it’s already playable on accelerated Amiga systems. You can generate maps, build transport routes, buy vehicles, set orders and run a working network. This isn’t just a program that reaches the title screen. It’s a real, usable port. However...

OpenTTD now runs natively on AmigaOS 3.x. That sounds simple. It isn’t. The new 68k port takes OpenTTD 1.0.5 and adapts it for AGA-equipped Amigas without relying on SDL or requiring an RTG graphics card. Instead, it talks directly to familiar Amiga system components, including Intuition, graphics.library and the machine’s planar display hardware. The current v0.4.1 build remains a work in progress, but it’s already playable on accelerated Amiga systems. You can generate maps, build transport routes, buy vehicles, set orders and run a working network. This isn’t just a program that reaches the title screen. It’s a real, usable port. However…

This took more than a recompile

OpenTTD normally draws its graphics into an 8-bit chunky framebuffer. AGA doesn’t work that way. It stores its 256-colour display across eight separate bitplanes, so the port has to convert the game’s graphics before the Amiga can show them. That conversion costs processor time.

To keep things moving, the video driver doesn’t redraw the whole screen whenever something changes. It tracks dirty rectangles instead. These are the areas affected by moving vehicles, opening menus, scrolling the map or updating interface elements. Only those sections get converted.

That makes a big difference on 68040 and 68060 systems. A complete 640 × 512 conversion is expensive, especially during busy games. Updating smaller areas reduces the workload and gives the processor more time to handle the simulation itself.

The port supports 320 × 256, 352 × 272, 640 × 480 and 640 × 512 display modes. The two lower resolutions are non-interlaced and should make the most sense on 68030 hardware. They reduce the pixel count and avoid the flicker associated with high-resolution interlaced AGA screens. Higher resolutions give you more room. They also ask much more from the machine.

The main game is already in place

Most of the core OpenTTD experience works. You can create maps, load and save games, use the scenario editor and manage transport companies. Railways, roads, stations and depots can all be built. Vehicles can be purchased, assigned routes and sent out to earn money. Mouse and keyboard controls are supported, so you don’t have to learn an unusual input system just because you’re running the game on an Amiga. There are limits, of course.

Networking isn’t available, and neither is music. The graphics driver currently supports AGA only, although RTG support is planned. OCS and ECS machines aren’t part of the target because OpenTTD needs a 256-colour display. This is still development software. Expect rough edges. Even so, the current build already covers the part that matters most: playing the game.

Paula handles the sound

The sound system takes a direct approach. OpenTTD’s effects play through Paula’s four hardware audio channels. The port prepares each sound, assigns it to a free channel and lets DMA handle playback. Once a sample starts, the CPU doesn’t need to mix it continuously in software. That saves valuable processing time.

OpenSFX samples are converted from 44.1 kHz, 16-bit audio to 22.05 kHz, 8-bit data and stored in Chip RAM. Paula’s hardware registers control volume and stereo positioning. There’s an obvious restriction. Paula only has four channels. When they’re all busy, any additional sound effect gets dropped. It’s a sensible compromise. Software mixing would put extra pressure on hardware that’s already working hard to run the simulation and convert the graphics.

You’ll need an accelerated Amiga

The minimum specification sets a clear baseline. You’ll need an AGA Amiga running AmigaOS 3.0 or 3.1, a 68030 processor, an FPU and at least 16 MB of Fast RAM. A 40 MHz 68040 is recommended, while a 50 MHz 68060 is the preferred option for full-speed play.

A basic 68030 may start the game, but don’t expect large maps and high-resolution modes to run comfortably. Lower resolutions should help, though busy transport networks will still increase the load.

The FPU requirement may seem surprising because OpenTTD performs most of its simulation with integer calculations. The issue comes from floating-point routines used during map generation and by the compiler’s runtime support. That rules out EC and LC processors without a working FPU.

OpenTTD 1.0.5 suits the hardware

Choosing OpenTTD 1.0.5 makes practical sense. It uses C++03, works with the available GCC toolchain and still includes an 8-bit rendering path that fits the chunky-to-planar conversion process. It also supports OpenGFX and OpenSFX, so you don’t need data files from the original Transport Tycoon Deluxe.

There’s still plenty to improve. Performance tuning, memory reduction and RTG support remain on the list. But the direction already looks right. This port doesn’t pretend an Amiga is a modern PC. It works with the hardware it has, cuts costs where possible and uses AGA and Paula directly. That’s exactly why OpenTTD now feels like an Amiga program rather than a desktop game awkwardly pushed onto one.

Spread the love
error: