Better Outrun port for Amiga

[eXeler0]

Could someone with the right know how explain how the Mega Drive version can both look and play better than the Amiga version? (Apart from the obvious poor coding on the Amiga version).
The Mega Drive has about the same CPU power, the secondary Z80 cpu was mostly used for sound. But most importantly, the megadrive only has 64k (72?) RAM and 64k video ram. Im sure loading off the cart can work around some of the ram limitations but still.. 64k video memory is not a lot.

[vulture]

MD is capable of 80 hardware sprites. Of course Amiga has bobs, copper, tricks and all, but it was completely straightforward to make a good port for MD, while on miggy it needed all the extra work.

[ReadOnlyCat]

Originally Posted by eXeler0

Could someone with the right know how explain how the Mega Drive version can both look and play better than the Amiga version? (Apart from the obvious poor coding on the Amiga version).
The Mega Drive has about the same CPU power, the secondary Z80 cpu was mostly used for sound. But most importantly, the megadrive only has 64k (72?) RAM and 64k video ram. Im sure loading off the cart can work around some of the ram limitations but still.. 64k video memory is not a lot.

As Vulture mentioned, the MegaDrive can display a lot more sprites than the Amiga and these are much better than the Amiga's puny ones (320 pixels of 16 color sprites per scanline just to give you an idea).
You can probably display more pixels with MegaDrive sprites than you can with the blitter in pure copy mode (and there is generally little point in using pure copy mode for games since masking often requires two channels).
Also you get 64 colors per scanline in dual playfield by default which means the road and roadside objects can be drawn completely independently.

Unless games are specifically tailored to the Amiga's strong points it is really hard for a non accelerated Amiga to reach MegaDrive quality.
Now, clearly that does not mean that MD games are always better since developer quality is a multiplying factor which sometimes can be quite low.

But look up "Alien Soldier" or "Gunstar Heroes" or "Contra Hard Corps", these would be really tough to port on an A500 without important compromises.

[Adrian Browne]

Originally Posted by ReadOnlyCat

As Vulture mentioned, the MegaDrive can display a lot more sprites than the Amiga and these are much better than the Amiga's puny ones (320 pixels of 16 color sprites per scanline just to give you an idea).
You can probably display more pixels with MegaDrive sprites than you can with the blitter in pure copy mode (and there is generally little point in using pure copy mode for games since masking often requires two channels).
Also you get 64 colors per scanline in dual playfield by default which means the road and roadside objects can be drawn completely independently.

Unless games are specifically tailored to the Amiga's strong points it is really hard for a non accelerated Amiga to reach MegaDrive quality.
Now, clearly that does not mean that MD games are always better since developer quality is a multiplying factor which sometimes can be quite low.

But look up "Alien Soldier" or "Gunstar Heroes" or "Contra Hard Corps", these would be really tough to port on an A500 without important compromises.

I'm thinking Mortal Combat 1 and 2 are exceptions to this rule.
I believe the Amiga version of MK 1 is better than the megadrive and the snes version has no blood or fatalities.

[Dunny]

Originally Posted by Adrian Browne

I'm thinking Mortal Combat 1 and 2 are exceptions to this rule.
I believe the Amiga version of MK 1 is better than the megadrive and the [b
]snes version has no blood or fatalities.[/b]

I'm not sure that this is due to the Amiga being a superior machine in this case.

D.

[dlfrsilver]

Originally Posted by eXeler0

Could someone with the right know how explain how the Mega Drive version can both look and play better than the Amiga version? (Apart from the obvious poor coding on the Amiga version).
The Mega Drive has about the same CPU power, the secondary Z80 cpu was mostly used for sound. But most importantly, the megadrive only has 64k (72?) RAM and 64k video ram. Im sure loading off the cart can work around some of the ram limitations but still.. 64k video memory is not a lot.

1 tile is coded on 1 bytes. 1kb is 1000bytes. the megadrive has 64kb, so that means 65535 tiles.

Memory on consoles using tilemaps and computers can't be compared.

Just to compare, the CPS-1 system from Capcom use 384kb of RAM.

It equals having up to 20mb+ of ram on a computer which use chunky or planar.

[vulture]

@dlfrsilver

1 tile on 1 byte? 8 bits? That's a very low amount of info it can carry. Are you sure that was the case for all consoles? I could be well off on the tile concept, but isn't the maximum an 1 byte can carry 8 pixels of 2 possible colours? Or is this just the minimum possible amount of memory a tile can consume?

Then again, isn't that a real RAM advantage only if many tiles are repeated to cover a large part of the area? Which is, of course, a frequent phenomenon, building a floor of tiles or large parts of the background etc.

[nobody]

I guess megadrive stores one 8x8 tile for an 68000 word which is 2 bytes (?)

A 16x16 tile would be 8 bytes then, so 64kb=8192 tiles but you have to store tiles and tilemap and sprites in the same VRAM (64kb) so the tiles capacity is smaller.

[vulture]

Yup, and that's for just 2 colours, right?

[ReadOnlyCat]

Tiles on the MD/Genesis are square blocks of 8x8 pixels (in non interlaced mode) and the data structure used to reference one is a 16 bits word. The tile itself uses a single 16 colors palette (specified in the referencing word) so each pixel of a tile takes only 4 bits.
(SNES/Super-Famicon also has 16 colors tiles but it has 16 palettes to choose from instead of 4 on the MD.)

Each background layer however, requires a rectangular matrix of tiles (64x32, 64x64, 128x32, etc.) the size of which cannot exceed 8KB. So in essence, each layer takes maximum 8KB of "screen memory", not counting the tiles it references. There are always two background layers.
The MD/Genesis has also scroll tables which allow it to scroll each line individually, as well as each column of tiles (every 8 horizontal pixels).

It should be fairly trivial to draw a raster road with tiles and the only problem on the Sega kitten is that the 68k cannot directly access VRAM where the tile matrices are stored so it has to maintain its own (partial) copy in RAM (maybe ROM too but I'm not sure) then use the DMA copy function of the VDP (Video Display Processor) to transfer it to VRAM. The DMA can copy 204 bytes during the horizontal blank so it's fast enough to replace the two layers's matrices each VBL but the CPU gets stalled for every DMA access.

As is the case with the Amiga, it's always a matter of choosing the best compromises but the machine has definitely more power at its disposal even with these restrictions.

[dlfrsilver]

Originally Posted by ReadOnlyCat

Tiles on the MD/Genesis are square blocks of 8x8 pixels (in non interlaced mode) and the data structure used to reference one is a 16 bits word. The tile itself uses a single 16 colors palette (specified in the referencing word) so each pixel of a tile takes only 4 bits.
(SNES/Super-Famicon also has 16 colors tiles but it has 16 palettes to choose from instead of 4 on the MD.)

Each background layer however, requires a rectangular matrix of tiles (64x32, 64x64, 128x32, etc.) the size of which cannot exceed 8KB. So in essence, each layer takes maximum 8KB of "screen memory", not counting the tiles it references. There are always two background layers.
The MD/Genesis has also scroll tables which allow it to scroll each line individually, as well as each column of tiles (every 8 horizontal pixels).

It should be fairly trivial to draw a raster road with tiles and the only problem on the Sega kitten is that the 68k cannot directly access VRAM where the tile matrices are stored so it has to maintain its own (partial) copy in RAM (maybe ROM too but I'm not sure) then use the DMA copy function of the VDP (Video Display Processor) to transfer it to VRAM. The DMA can copy 204 bytes during the horizontal blank so it's fast enough to replace the two layers's matrices each VBL but the CPU gets stalled for every DMA access.

As is the case with the Amiga, it's always a matter of choosing the best compromises but the machine has definitely more power at its disposal even with these restrictions.

Thanks for correcting me So it's coded on a word like on CPS-1 arcade board

the consoles are more "dedicated", in the sense that the 68000 is asking for the VDP to push on the screen the tiles via the tile word reference.

[ReadOnlyCat]

Originally Posted by dlfrsilver

Thanks for correcting me So it's coded on a word like on CPS-1 arcade board

I do not know the origin of the CPS-1 board but since the MegaDrive apparently is a scaled down version of Sega's arcade boards it probably shares many other similarities with arcade systems of that time.

Originally Posted by dlfrsilver

the consoles are more "dedicated", in the sense that the 68000 is asking for the VDP to push on the screen the tiles via the tile word reference.

It is true that consoles are designed for a very specific workflow where the 68k is the director of operations. But even if the hardware is designed with a relatively "standard" procedure of operation in mind it is interesting to note that - just like the Amiga chipset - it can be subverted to operate in ways completely unforeseen by the original designers.

A great example is the MD's true color graphical mode "invented/discovered" around 2012: the machine best display mode is normally 320x224 in 64 colors and given it is using tiles for both backgrounds and sprites it can display maximum 48 colors on any single tile (16 from layer A, 16 from layer B, 16 from a sprite) of 8x8= 64 pixels. And the palette colors can only be changed during horizontal blank otherwise undesired dots start appearing on the line of the change.
But people discovered that if you shut down the display, synchronize with the display raster, and use the DMA to send a constant stream of color values to color 0, the DMA is fast enough to essentially push 160x224 color values on screen which then form a true color 9 bit image!

It's essentially the same principle as copper chunky but with a twice better resolution and alas only 512 colors instead of the Amiga 4096.
Given that this heavily taxes the memory bus one cannot do much else during that time but still a great technique to display true color static images on a system which was never designed for it.

But yeah, forget about running OutRun in this mode!

Addendum:
For the technically oriented kittens among youse, I recommend this spritesmind thread about the Direct Color mode, it gives a lot of interesting information about how they achieved it.

[s2325]

Maybe it's possible to use Lotus 96k code as it's not so old and need low CPU.

[Lonewolf10]

Originally Posted by ReadOnlyCat

Addendum:
For the technically oriented kittens among youse, I recommend this spritesmind thread about the Direct Color mode, it gives a lot of interesting information about how they achieved it.

Thanks for posting the link. That was an interesting read

[eXeler0]

Hypothetically speaking.. if one would try to grab the graphics and sound from the ROM for an exact port, instead of recreating it from scratch, are there tools for that?

[dlfrsilver]

It's more complicated than that.

1) The palettes are spread in the code
2) The backgrounds are planar
3) .... but the sprites are in chunky mode ! (that's why it can't be seen under mame).

The sega games would need a tool which would read the palette inside the game rom code, and used in conjunction with sprites and background roms, and allowing saving the sprites with their colors, as well as the background.

With this, it would be easier to see how hard it would be to make a faithfull port in 256 colors for A1200

[Retro1234]

Its going to be very hard to port anything to Amiga because its such a big project and people are realizing this and people who made these games back in the day were legends. If you look at something like what AnimaInCorpore has been doing and can get just Text outputs from Arcade games it might be possible - I would think to start recreating theses formulas - getting the same text values outputed and then start putting graphics in - one Huge task!

[eXeler0]

Originally Posted by dlfrsilver

It's more complicated than that.

1) The palettes are spread in the code
2) The backgrounds are planar
3) .... but the sprites are in chunky mode ! (that's why it can't be seen under mame).

The sega games would need a tool which would read the palette inside the game rom code, and used in conjunction with sprites and background roms, and allowing saving the sprites with their colors, as well as the background.

With this, it would be easier to see how hard it would be to make a faithfull port in 256 colors for A1200

Are you saying that it would be easier to somehow intercept whatever MAME is feeding into the framebuffer instead of trying to interpret the code in the original ROM?

[ReadOnlyCat]

Originally Posted by dlfrsilver

It's more complicated than that.

1) The palettes are spread in the code
2) The backgrounds are planar
3) .... but the sprites are in chunky mode ! (that's why it can't be seen under mame).

I am a bit surprised that the background would be planar given that these layers are tile based. There is little advantage to defining tiles content using a planar layout and the MegaDrive/Genesis uses chunky pixels for tile content for example. Do you have a link to your source?

Also it would not be too hard to create custom sprite viewers by changing the palette with the copper. It would be easy to display several sprites per scanline provided the underlying palette is changed on the fly.
Zoomed in full color versions could also use copper chunky.

There are plenty of ways to display high color content on OCS Amigas if one is willing to build dedicated viewers.

[eXeler0]

@ ReadOnlyCat hypothetically speaking of course ;-) How would you go about this... if you'd reverse engineer a game and extract assets to get the most faithful port possible (never mind OutRun.. in general)