OutRun: I started porting it!

[reassembler]

Hello all! I hope this is posted in the right area.

Over christmas I decided to teach myself some Amiga programming basics. I already had a moderate knowledge of 68k assembly, and I'd recently retrieved the Amiga from the loft and pimped it up. Time to party.

In terms of tools and references, I used:
- VSCode Amiga Assembly (what an awesome project!)
- Bare Metal Amiga Programming
- The Amiga Hardware Reference Manual
- Mountains of Python scripts to translate data structures and remap things for speed optimization.

This was enough to get me going. From my previous CannonBall project and work on arcade hardware, I have the entire OutRun codebase decompiled and documented.

HOW HARD COULD THIS BE?

Pretty hard! I made the decision to target AGA with a modest accelerator (TerribleFire 1230). Mostly because this is the hardware I have sat in front of me. And let's face facts - if this is to be an arcade port of sorts, rather than a rewrite or my own interpretation of OutRun, it's not going to run on the A500.

Anyway, I started by porting the road code and simulating the custom road hardware. This may not sound particularly fascinating, and perhaps it isn't that sexy. But in reality, the entirety of the OutRun engine is based around the road hardware and corresponding code working correctly.

For those not familiar with Sega's hardware, it's 2 x 68000 processors clocked at 10Mhz and a Z80 to drive audio. There are a significant number of custom graphics chips, which really do all of the heavy lifting, and represent the most significant translation challenge. To give you an idea, I tried a naive yet optimized port of the MAME road rendering code to 68K and it took about 8 vblanks to render a single frame on an accelerated 030! HAH! And that was without any game code running.

For the road rendering, OutRun dedicates an entire 68000 processor, plus custom road rendering hardware - pretty advanced for its day! In fact, even the master 68000 also gets involved in controlling the road width, applying height maps, the road split at the end of the level and beyond. So there are two 68Ks chipping away at this thing.

Obviously this is one reason OutRun is/was the boss of 2D racers. Flexible road widths, dynamic road palette, roads splitting into lanes, undulating landscapes. The road, well roads, as it can render two are important.

As far as possible I've tried to keep the original 68K code intact for now. It's a line by line port. The main changes have been to the data structures (palettes, the road rom and various other madness) in a vague attempt to marry it with Amiga hardware expectations and my frankenstein Amiga code.

After rewriting the entire road hardware layer about 7 times - and I really mean that - I landed on a solution pairing the Copper and Blitter with some ingenuity. This is mostly OutRun ingenuity, as opposed to anything revolutionary for the Amiga. My Amiga programming is probably bad.

One thing I'm particularly excited about is I managed to streamline the entire road priority system, which is a beast... handled on a per-pixel basis on MAME, where every single road pixel is cross referenced against a priority table and compared with the 'other road' to determine which pixels should be shown... to a single minterm blit per plane and a complete rework of how a road is represented in memory.

So right now, we have implemented:
- Ability to load the original level data
- Correct palette colours
- Road Hardware Layer: Width, Height, Direction, Lanes, Palettes
- Complete 68000 Sub CPU Codebase ported
- Some basics from the Master CPU ported
- Road Splits
- The ability to move through a level with the keyboard

Just to be clear: I'm not sure how far I'll get with this project. It's a tough cookie. I've poured a lot of energy into the basics and it's been a great and somewhat painful learning experience. Next up, it probably makes sense to get some sprites rendering, maybe scaling. I'll probably run out of colours, megahertz or sanity before then though. Or maybe just go to the pub.

Today, I tried this on hardware for the first time. MUHUH. Did it run? Cliffhanger, watch the video below.

[ Show youtube player ]

[Samurai_Crow]

I agree that attempting Arcade OutRun on a stock system would be a fool's errand, due mainly to bandwidth bottlenecks in the AGA chipset itself. It's good to see such early progress. I hope you've left some bandwidth for scaling textures! How many bitplanes do the current versions use?

[Trapshot]

Dear lord.... if you succeed in this you will make a lot of people very happy!

[copse]

Nice progress! Love the initiative and looking forward to seeing where you get.

[Reynolds]

Fingers crossed. I'd like to see something next to Lotus Turbo Challenge 2 when I'm in the mood of driving. Wish you luck to successfully complete it.

[kriz]

This rocks!!

[DanyPPC]

If you develop it on an hardware like ApolloV4 then you have zoom and scaling via hardware, so the game should be like the original arcade.

On simple A1200 it can be a challenge.

[malko]

KUDOS for the work done so far
Even if it is an accelerated Amiga (68030) I am impressed by the actual speed of the road given the description of the arcade engine you gave.
Keep up the good work .
Eager to read more.

[jotd]

IMHO you're on the right track trying to get "lucky" with software requiring superior hardware but where you can do specific things using copper & blitter & whatever so it works, not targeting a generic "engine" that would crawl anyway

Another example of requiring extra power, because if you reimplement parts to save CPU you end up not being able to use the rest of the original code at all. I had the same issue with modest Tetris and its dynamic palette, requiring AGA to run.

The fact that it will run on 030/fast is great. 020/nofast just can't cope.

[reassembler]

Originally Posted by Samurai_Crow

I agree that attempting Arcade OutRun on a stock system would be a fool's errand, due mainly to bandwidth bottlenecks in the AGA chipset itself. It's good to see such early progress. I hope you've left some bandwidth for scaling textures! How many bitplanes do the current versions use?

Yes. If there is detailed AGA/020 documentation out there regarding performance, DMA and so forth it would be of genuine use. I find it difficult to comprehend how UAE speeds will translate to real hardware, even though (I hope) I've configured the emulator with all the settings to match my hardware setup. To be honest, I was absolutely flabbergasted it ran first time - albeit with performance and keyboard related oddities. I'm also unsure whether the VSCode Amiga Assembler maintainers will be upgrading the version of UAE bundled with it.

I'm currently using 3 bitplanes for the road. I suspect this is one too many. However, some of the roads use > 4 colours once you account for transparency and the 'striping' effect that's applied as the road moves. I've offloaded the background and sky colouring to the copper, as they use loads of colours. There's a subtle colour shading effect, for example, as the ground meets the horizon. And some of the OutRun skys use gradients too. (I appreciate most will be familiar with the wall of Sega blue of Stage 1, but later levels do a bit more than this). So right now - it's 'arcade perfect' in terms of this portion. But I'm willing to kill a bitplane, if needs must.

I do appreciate there's better Amiga hardware out there, but I'd like to strike a compromise between what I (could have) had back in the day - I didn't have an accelerator but would have bought one for OutRun - and modern enhancements.

The sprites are going to be interesting, scaling aside. I ran some Maths on the number of scenery sprite palettes used on Stage 1.... and from memory we were already clocking in at 350+ colours.

You can see from looking at Lotus, how many smart development decisions were made based upon the target hardware paired with solid programming.

[Samurai_Crow]

@reassembler
You're just starting with the killing of 1 bitplane. You will end up killing more than that once you figure that transparency is best done using CPU drawing or blitting directly to the sprite channels! The AGA blitter is anemically identical to ECS and OCS. Transparent "cookie-cutter" blits take more bandwidth than needed and when lots of bitplanes are involved... Yikes!

Also, once you start using more than a few bitplanes you'll find out that being able to double-buffer sprite palette changes using the even and odd sprite bank color selectors is worth losing the 8th bitplane! Using palette registers by the sprite hardware instead lets you do color changes during the visible display with the Copper! The catch is: How much can you do with 3 palette entries per sprite per row? 24 colors per row with normal, 3 color sprites, or 15 per row with stacked sprites.

[reassembler]

Originally Posted by Samurai_Crow

Transparent "cookie-cutter" blits take more bandwidth than needed and when lots of bitplanes are involved... Yikes!

I'm not using the cookie-cutter functionality of the blitter - at least not in the way I think you mean, based on the hardware docs. Its current purpose is for the free shifting it provides, due to the horizontal offset applied to each line of the two roads. My use of the blitter is pretty basic right now.

I've reworked the road data itself so that the below horrendous statement (pulled from the Mame source code and implemented in software) is no longer required to combine the roads. I just sent a basic minterm to the blitter and toggle channels A and B (mapped to each road).

 
*  Out Run road priorities are controlled by a PAL that maps as indicated below.
 *  This was used to generate the priority_map. It is assumed that X-board is the
 *  same, though this logic is locked inside a Sega custom.
 *
 *  RRC0 =  CENTA & (RDA == 3) & !RRC2
 *      | CENTB & (RDB == 3) & RRC2
 *      | (RDA == 1) & !RRC2
 *      | (RDB == 1) & RRC2
 *
 *  RRC1 =  CENTA & (RDA == 3) & !RRC2
 *      | CENTB & (RDB == 3) & RRC2
 *      | (RDA == 2) & !RRC2
 *      | (RDB == 2) & RRC2
 *
 *  RRC2 = !/HSYNC & IIQ
 *      | (CTRL == 3)
 *      | !CENTA & (RDA == 3) & !CENTB & (RDB == 3) & (CTRL == 2)
 *      | CENTB & (RDB == 3) & (CTRL == 2)
 *      | !CENTA & (RDA == 3) & !M2 & (CTRL == 2)
 *      | !CENTA & (RDA == 3) & !M3 & (CTRL == 2)
 *      | !M0 & (RDB == 0) & (CTRL == 2)
 *      | !M1 & (RDB == 0) & (CTRL == 2)
 *      | !CENTA & (RDA == 3) & CENTB & (RDB == 3) & (CTRL == 1)
 *      | !M0 & CENTB & (RDB == 3) & (CTRL == 1)
 *      | !M1 & CENTB & (RDB == 3) & (CTRL == 1)
 *      | !CENTA & M0 & (RDB == 0) & (CTRL == 1)
 *      | !CENTA & M1 & (RDB == 0) & (CTRL == 1)
 *      | !CENTA & (RDA == 3) & (RDB == 1) & (CTRL == 1)
 *      | !CENTA & (RDA == 3) & (RDB == 2) & (CTRL == 1)
 *
 *  RRC3 =  VA11 & VB11
 *      | VA11 & (CTRL == 0)
 *      | (CTRL == 3) & VB11
 *
 *  RRC4 =  !CENTA & (RDA == 3) & !CENTB & (RDB == 3)
 *      | VA11 & VB11
 *      | VA11 & (CTRL == 0)
 *      | (CTRL == 3) & VB11
 *      | !CENTB & (RDB == 3) & (CTRL == 3)
 *      | !CENTA & (RDA == 3) & (CTRL == 0)

[Samurai_Crow]

@reassembler
Great! The masked blitting mode for making Bobs is a waste of time! You'll get more colors from the Copper palette changes than you ever would have with bitplanes and blitter.

If you find yourself using only 15 foreground colors per row and 8 background colors for the road, don't be surprised by the fact that dual-playfield mode buys you more with its maskless transparency than the palette entries lost. The copper is a more powerful source of color entries than palette entries in the main bitplane DMA channels. The same bank-selector trick works for playfields as sprites!

[reassembler]

Originally Posted by Samurai_Crow

If you find yourself using only 15 foreground colors per row and 8 background colors for the road, don't be surprised by the fact that dual-playfield mode buys you more with its maskless transparency than the palette entries lost. The copper is a more powerful source of color entries than palette entries in the main bitplane DMA channels. The same bank-selector trick works for playfields as sprites!

Good to know. Actually thinking about the Copper in relation to your above comment made me realize I can probably quite easily lose a road bitplane without sacrificing anything.

That being said, I've spent so long on the road stuff I'm keen to move onto sprites next.

[jotd]

I remember using dual playfield (AGA) for Xevious, which gave me 16+16 colors without merging the bobs with a background (only together), which is also much easier to handle.

then I also remember using sprites for some objects. By combining 4 sprites you can create 128-pixel-wide objects with 7 colors, upping to 8 sprites at the same location you could even use 16 colors maybe more and use that for the car which is always displayed.

[kkgarbod]

Nice. Another port to look forward too. Know someone is porting Outrun to the Apple II.

[tin]

Loving this, will follow along.

[pixie]

It would be amazing if you'd do a series on YouTube like kk Altair did with dread!

[trixster]

Originally Posted by kkgarbod

Nice. Another port to look forward too. Know someone is porting Outrun to the Apple II.

To the X68000 instead, please!

[pink^abyss]

Well done!
I wonder how much the blitter will slow it all down when it comes to blitting the gazillon
of sprites in Outrun...

Although very simple in comparison to Outrun I was prettry amazed back then by the
Super Hang On demo OCS@50fps [ Show youtube player ]