Arcade / Console --> Amiga conversion discussions

[kovacm]

Originally Posted by ovale

Regarding to a possible OCS version, there is no doubt Fast RAM is required to pair the STE requirements.

With 16 colors the 68k has always free access to chipram when blitter is not used. So a straight port from STE (no Blitter use) will have 7.19/8 the speed of STE (10% slower).

But, since we have fast RAM we can exploit the parallelism that exists between CPU and Blitter. This is a specific advantage of the Amiga architecture (and by the way it is a shame the A500 didn't integrate 32K of Fast RAM from day one).

For example, it is possible to draw the sprites in fast RAM with the CPU while the blitter renders the tiles from a LRU cache in chip RAM.

I am eager to see what can be accomplished on Amiga

but please,if you can, explain me what you will do with "sprites drawn in fast RAM by CPU"? How you will put it in screen (move it to chip RAM)? How much bus time and CPU time it (transfer from fast to chip ram) will cost?

[AnimaInCorpore]

Originally Posted by ovale

If you don't mind put the STE version on GitHub then someone could pick it up contribute and port it to other platforms over time without having to commit here now.

Good point but I have some concerns about the legality of putting the source code online. That also means that a possible release version probably wouldn't include the original program binaries so that you have to obtain it from some other places.

OTOH the source code is not yet fully relocated so it would need some additional work to find all address locations. This makes it quite hard to get it working at a different location than the original first megabytes of RAM.

[sandruzzo]

We don't need CPU to do Blitters' job. We need CPU to go as fast as possible. With FAST RAM we can do thata

[ovale]

Originally Posted by AnimaInCorpore

Good point but I have some concerns about the legality of putting the source code online. That also means that a possible release version probably wouldn't include the original program binaries so that you have to obtain it from some other places.

OTOH the source code is not yet fully relocated so it would need some additional work to find all address locations. This makes it quite hard to get it working at a different location than the original first megabytes of RAM.

Ah, I see your point. Maybe you can put in GitHub only the tools, build system and patches. People will have to find the ROM and run the build. I think this is less risky but off course is up to your propensity to risk. Anyway I think they will go after Mame before coming knocking to your door . I mean, a port for some dead platforms has an economic value near to zero and lawyers cost, a lot.

[ovale]

Originally Posted by kovacm

but please,if you can, explain me what you will do with "sprites drawn in fast RAM by CPU"? How you will put it in screen (move it to chip RAM)? How much bus time and CPU time it (transfer from fast to chip ram) will cost?

My reasoning is that when tiles priority and the second layer of tiles will be introduced the code will spend lot of time drawing tiles and sprites. I guess game logic is not a big deal.

In this context if the Blitter does the drawing then the CPU will sit most of the time idle waiting for the end of the blit. To leverage the parallelism we have to balance the load between the two.

An idea can be: have the CPU render the sprites (my understanding is that Anima already implemented compiled sprites) with the background already there. This will require N>2 memory access for each 16 pixel row. So it is compelling to do it in fast RAM without bus contention.

When done the CPU will copy these "tiles with sprites on top" in Chip RAM. This can be pretty efficient since is almost contiguous memory. It will also copy new tiles in the LRU tile cache in Chip RAM.

In the meanwhile the Blitter is working on the frame F-1, drawing animated tiles, tiles entered by scrolling, and merging the second layer of tiles. Plenty of work.

It should be faster compared to do everything with the 68k. People smarter than me could even figure out clever ways to split the work.

Hope it makes sense.

[sandruzzo]

Originally Posted by ovale

My reasoning is that when tiles priority and the second layer of tiles will be introduced the code will spend lot of time drawing tiles and sprites. I guess game logic is not a big deal.

In this context if the Blitter does the drawing then the CPU will sit most of the time idle waiting for the end of the blit. To leverage the parallelism we have to balance the load between the two.

An idea can be: have the CPU render the sprites (my understanding is that Anima already implemented compiled sprites) with the background already there. This will require N>2 memory access for each 16 pixel row. So it is compelling to do it in fast RAM without bus contention.

When done the CPU will copy these "tiles with sprites on top" in Chip RAM. This can be pretty efficient since is almost contiguous memory. It will also copy new tiles in the LRU tile cache in Chip RAM.

In the meanwhile the Blitter is working on the frame F-1, drawing animated tiles, tiles entered by scrolling, and merging the second layer of tiles. Plenty of work.

It should be faster compared to do everything with the 68k. People smarter than me could even figure out clever ways to split the work.

Hope it makes sense.

We have blitter which is almost allways faster than 68000. We can better use this cpu with fast ram...

[sandruzzo]

I was wondering if with 256*192 32 colors screen and 20-30% smaller bob, we can have Final Fight at 50hz scrolling and 25hz bobs..

[zero]

For games like Final Fight, scrolling is the least important thing. You need the game engine running at 50Hz, i.e. the sprites.

[sandruzzo]

Originally Posted by zero

For games like Final Fight, scrolling is the least important thing. You need the game engine running at 50Hz, i.e. the sprites.

I don't think is possible on A500

[dlfrsilver]

Originally Posted by sandruzzo

I don't think is possible on A500

Those games are mostly made to be converted on 32 bits machines.

The 1200 is the most indicated computer for that. or you would need soupped-up machines A500.

[sandruzzo]

Originally Posted by dlfrsilver

Those games are mostly made to be converted on 32 bits machines.

The 1200 is the most indicated computer for that. or you would need soupped-up machines A500.

Yes, But A500 would be a Huge challenge!

[ross]

This thread is really interesting.
Anima work is excellent.

What I think: A500 can be challenging and the final result disappointing..

I'm for an A1200/030/8+MB conversion, with this specs a really good conversion can be made.
But not a one man work.. The various scroll/sprite/blitter_objects routines need to be (re)written, the game logic also.
The same for graphics/audio.

We need some unemployed talented people
[I'm alway in a chronic 'lack of time' situation..]

Bye,
ross

[dlfrsilver]

Yes Anima did an awesome job, there's no tale to tell on that matter.

When i see Ghouls'n'ghosts like that, i see Strider, i see Final Fight.

the Ste version, even without the back layer is already so awesome to look, and it moves very good ! Frankly, what a surprise !

[sandruzzo]

We need to do a port that wasn't already done...

[kovacm]

Originally Posted by ross

This thread is really interesting.
Anima work is excellent.

What I think: A500 can be challenging and the final result disappointing..

I'm for an A1200/030/8+MB conversion, with this specs a really good conversion can be made.
But not a one man work.. The various scroll/sprite/blitter_objects routines need to be (re)written, the game logic also.
The same for graphics/audio.

We need some unemployed talented people
[I'm alway in a chronic 'lack of time' situation..]

Bye,
ross

Anima already did this: he converted 50 games from Neogeo to Atari Falcon: http://www.atari-forum.com/viewtopic...rt=100#p254304

Here you have Metal Slug running on standard 16MHz Falcon (Anima mention that it could be faster since there are some unnecessary clearing):

[ Show youtube player ]

and here is same Metal Slug running on Falcon with Phantom accelerator (25MHz original CPU and BUS):

[ Show youtube player ]

judging by this videos, I would say that it will be quite playable on 50MHz 68030.

[zero]

The Neo Geo has sprite scaling though, so it's gonna be hard to port those games to any system that can't do horizontal scaling in hardware.

[kovacm]

Originally Posted by zero

The Neo Geo has sprite scaling though, so it's gonna be hard to port those games to any system that can't do horizontal scaling in hardware.

hm... I am not sure if you did not understand what I wrote: Anima already did it. Yes, some games are super slow but some could be playable on 50MHz 68030...

[ross]

Originally Posted by kovacm

Anima already did this: he converted 50 games from Neogeo to Atari Falcon

The games is not converter, is emulated (and it's an amazing work from Anima).

judging by this videos, I would say that it will be quite playable on 50MHz 68030.

"playable" is not the right word here

Bye,
ross

[kovacm]

@ross you are right - emulated but I was referring on 500MB archive for Falcon.


and if you can not imagine how Metal Slug would look like at 50MHz then click on "Settings" on youtube and choose "Speed: 2x"

btw
problem is that this would not work on Amiga right away since you have only 2MB of chip RAM for graphics and you would need to copy data from FastRAM all the time.
What is speed of fast>chip copying with 50MHz 68030 on AGA Amiga?

[ross]

Originally Posted by kovacm

What is speed of fast>chip copying with 50MHz 68030 on AGA Amiga?

A speed calculation (tentative, raw):
in all Amiga systems chip ram access is fixed (so even the fastest accelerator cannot exceed some speed).

It's accessible for the CPU every 2CCK so every 1/(3546895/2)=563,87ns (32bit at a time for AGA).

This corresponds to a maximum transfer of (1/563,87e-9)*4/2^20=6,765MB/sec (comma is a decimal separator, european mode).
But this is only theoretical: impossible to make a stream from fast to chip without recharging somehow CPU registers and all DMA need to be off..
Moreover fast/chip interface does not run at full efficiency in most accelerator boards. Typical 80-90% is the case.

I've made a simple test: a 16x movem.l d0-a7,(a0) (a0 in chip) so a burst of 1KB data from CPU (all DMA off).
This got me a time of ~535CCK -> ~(1/3546895)*535 -> ~150us -> ~6,47MB/sec.

If you need to copy from fast, have 8bpl+sprite+audio DMA and code that make something, figure a minimum /2 performance so if you got ~3MB/s you are lucky

3MB/sec equal to 3072/50frame~=60KB/frame
If your game view is 320*256*8 you need ~80KB/frame...

What can be done:
- parallelise CPU/blitter usage (for 030 there is some gain)
- restrict view
- make a 25fps game
- write a great fast/chip data mover (there is some Kalms c2p 8bpl/lores which reaches 83kB/frame, but with a 060/50Mhz..).


ross