Arcade / Console --> Amiga conversion discussions

[dlfrsilver]

Originally Posted by zero

I think he is confused. He means that the CPS system supports 8MB of ROM that can contain graphic data for tiles and sprites. As you say, it's not RAM.

When doing an Amiga conversion, you would need to copy that data into RAM, so maybe he thinks you need 8MB of RAM for it... Assuming you don't load data between levels, and keep all the animations (impossible on Amiga due to blitter speed).

When you emulate a CPS game on a PC, for instance Ghouls'n'Ghosts, you need 16 megabytes of RAM.

CPS games use unified programs and graphic assets, since everything is accessible at the same time during execution.

And of course, the original hardware stores everything in ROM, the RAM is specific and used as cache ram to speed up the whole thing.

192kb of "graphic tile metadata ram" is huge. This means more than 192000 words can be stored in this ram. A tile in the CPS system is always coded on word boundaries likes "12FF".

The tiles metadata indicates in the specific ram the X and Y of the tile to display by the graphics chip.

That's how the printing of a tile on screen is done. the roms containing the graphic tiles is in fact used as a big database.

that's what i discovered when i got my hands inside the arcade program of Final Fight when i helped in the making of Final Fight AGA.

That's how i discovered that the CPS1 hardware had a custom assistance for the program operations, as well as the hardware/tiles operations, those including the ability to perform rudimentary rotations in hardware.

Damnd, the 1st boss of Final Fight has no sprite frames when he is rolling on screen. The CPS1 hardware performs rotations on a specific frames per 90°, and is propulsing the sprites during this event on the whole screen.

one of the undocumented registers is responsible for that, since there is no sprite frame built from tiles for that inside the graphic roms.

In fact, the Code/data repartition inside the program is like 250kb of code and the remaining is game data (read tiles metadatas).

The way the tile metadatas are organised show that the game code use a specific "parser" (in adventure games, a parser is used in a game to recognize specific patterns of events to process, but it can be used too in such games) to process the chained sprites, each with its position in X and Y, his own color palette, and the tile metadata to send to the graphic chips for display.

That's how i discovered that Haggar in the coin-op use 80 frames, the bad cop Edie.E use 43 frames, And Damnd something like 45.

[sandruzzo]

In my opinion Amiga 500 or ocs had small unleft things that would done with few costs:

16-32k fast mem for 68000
68000 8 mhz
ocs 8 mhz clock
enough dma slots to have ham6 in hires
asynchronous copper

[idrougge]

I don't think you can get any more DMA than already available "with few costs".

Regarding 8 MHz 68000, how can the ST have an 8 MHz processor while still generating a colour TV picture? Does it have a separate clock for graphics?

[roondar]

Originally Posted by idrougge

I don't think you can get any more DMA than already available "with few costs".

Regarding 8 MHz 68000, how can the ST have an 8 MHz processor while still generating a colour TV picture? Does it have a separate clock for graphics?

The Atari ST uses a custom chip called Shifter, which like Denise on the Amiga fetches graphics data using DMA. Shifter uses only half the bus cycles. The other half are available for the 68000.

Which as we know usually uses only half the bus cycles, so it doesn't lose cycles during display DMA.

[kovacm]

Originally Posted by sandruzzo

In my opinion Amiga 500 or ocs had small unleft things that would done with few costs:

16-32k fast mem for 68000
68000 8 mhz
ocs 8 mhz clock
enough dma slots to have ham6 in hires
asynchronous copper

Yea... and ST could have, at least, vertical hardware scroll for almost no cost if Atari decide to implement full register for screen address instead ST screen is bound to 256 bytes addresses because bottom eight bits of the base address simply doesn't exist on the ST (this is one of many proof that ST never was design as competitor to Amiga but rather to Apple Macintosh! Otherwise Atari would put complete base address register with almost no effort or cost.)

Originally Posted by roondar

The Atari ST uses a custom chip called Shifter, which like Denise on the Amiga fetches graphics data using DMA. Shifter uses only half the bus cycles. The other half are available for the 68000.

Which as we know usually uses only half the bus cycles, so it doesn't lose cycles during display DMA.

So MC68000 in ST can always access RAM in "full speed" (only non-4 cycle instruction will cause delay/waste cycles) and it is almost 4MB/s in practice.
What about Amiga 500 and chip RAM? MC68000 also can read/write 4MB/s if there is no contention from custom chips on bus/ram? Is speed also 4MB/s?

And what is speed of (real) FAST RAM in Amiga 500?

Originally Posted by idrougge

Because otherwise your fast RAM would be as slow as your chip RAM.

Or you only get half as many colours, like the ST.

hm... Shifter in ST do not even use available 4MB/s but rather around 2MB/s for 32KB screen (320x200 in 16 color, 60Hz; and somewhere more for 640x400 mono @71Hz on SM124) - rest of available memory cycle is used for memory refreshing. Someone claim that Atari use RAM outside manufacture specification to achieve this speed (4MB/s for CPU and 4MB/s for Shifter) so this additional refreshing cycles are necessary because of this.
But, what prohibit in ST design to have e.g. 32colors (5 bitplanes)? There is enough bandwidth for this...

[dlfrsilver]

So MC68000 in ST can always access RAM in "full speed" (only non-4 cycle instruction will cause delay/waste cycles) and it is almost 4MB/s in practice. What about Amiga 500 and chip RAM? MC68000 also can read/write 4MB/s if there is no contention from custom chips on bus/ram? Is speed also 4MB/s? And what is speed of (real) FAST RAM in Amiga 500?

The philosophy here is different for the Amiga.

On the amiga, the trick is to use the chipset to process all the things that are not related to the CPU role, and by this free the 68000.

You can then have a better game logic on the Amiga or do more things with the 68000 while the chipset take care of the graphics and sound.

This is why the CPU clocking is "not important" on Amiga, as well as the bandwith.

hm... Shifter in ST do not even use available 4MB/s but rather around 2MB/s for 32KB screen (320x200 in 16 color, 60Hz; and somewhere more for 640x400 mono @71Hz on SM124) - rest of available memory cycle is used for memory refreshing. Someone claim that Atari use RAM outside manufacture specification to achieve this speed (4MB/s for CPU and 4MB/s for Shifter) so this additional refreshing cycles are necessary because of this.
But, what prohibit in ST design to have e.g. 32colors (5 bitplanes)? There is enough bandwidth for this...

The ST is locked to 16 colors, as soon as you raise the bar, since everything is done with the CPU, you loose cycles. You can do multiple palettes, or on the fly palettes change on the screen, but then you kill completely the screen refresh. Shadow of the beast 2 on ST is a very good example of this.

They show 40-50 colors at the same time on screen, but you have then 8 frames only per seconds as compromise.

that's why even the best programmed games on ST shows visible limitations on screen. (and i'm not specifically talking about Beast....). Just pick Enchanted Lands, or any other game using the ST.....

[zero]

Originally Posted by kovacm

You insist that that CPS does not use planar bitmaps. Can we clear how background tiles work?

The tile bitmaps are planar, but it's not really relevant... They are generated by software on an X68000 and stored in ROM. The CPU never touches it, and there is no frame buffer or anything like that.

[zero]

I think the thing that would really have helped the Amiga would have been better sprites.

[idrougge]

Originally Posted by roondar

The Atari ST uses a custom chip called Shifter, which like Denise on the Amiga fetches graphics data using DMA. Shifter uses only half the bus cycles. The other half are available for the 68000.

Which as we know usually uses only half the bus cycles, so it doesn't lose cycles during display DMA.

What I was wondering was how the 8 MHz clock mapped to the picture generation. The Amiga's 7.xx clock maps directly to the PAL/NTSC colour clock.

[kovacm]

Originally Posted by idrougge

What I was wondering was how the 8 MHz clock mapped to the picture generation. The Amiga's 7.xx clock maps directly to the PAL/NTSC colour clock.

http://alive.atari.org/alive9/ovrscn1.php

"A picture is displayed 50 times a second in 50Hz mode (or 60 times in 60Hz). The
ST generates 313 lines per picture at 50Hz (263 at 60Hz). In theory, it should
generate 312.5 lines, (obtained by successively displaying 312 and 313 lines).
It therefore assumes the monitor can tolerate displaying a picture at 49,92Hz
instead of 50Hz. This also explains why the ST cannot have a real interlace mode
such as that of the Amiga. Each line takes a constant time to be transmitted:
otherwise the picture would be distorted. This time is calculated using the
following formula:

1
-------------------------------------------------------------
(Number of pictures per second * number of lines per picture)

For "Number of pictures per second"=50 and "Number of lines per picture"=312.5,
we get 64 microseconds. But some will wonder how come there are 313 lines, if I
only see 200 on the screen? The other lines are used by the upper and lower
borders, and by the vertical synchronization signal which tells the monitor
where the top of the screen starts. Overscan is the process of converting the
lines used to make up the borders into lines able to display a picture loaded
from memory. I will call "useable screen" that part of the screen not occupied
by borders."

[roondar]

Originally Posted by idrougge

What I was wondering was how the 8 MHz clock mapped to the picture generation. The Amiga's 7.xx clock maps directly to the PAL/NTSC colour clock

Ah, I misunderstood your question then. Though it seems to have been answered by now.

Originally Posted by kovacm

So MC68000 in ST can always access RAM in "full speed" (only non-4 cycle instruction will cause delay/waste cycles) and it is almost 4MB/s in practice.
What about Amiga 500 and chip RAM? MC68000 also can read/write 4MB/s if there is no contention from custom chips on bus/ram? Is speed also 4MB/s?

Atari ST memory speed should be somewhere near 4MB/s for reading or writing (though in practice the CPU will never reach that because of instruction decoding & looping requirements). Don't forget that any figures are only one-way, so a copy is half speed and a 'soft sprite' operation will be at most 1/4 of this.

Amiga memory speed is more complicated. Up to 4 bitplanes in lowres / 2 bitplanes in hires the CPU is, like the Atari, not slowed down (except on non-4 cycle multiples instructions). Since its clock speed is ~7MHz, the speed is then somewhere near 3.5MB/s.

When more bitplanes are used, memory speed goes down (5 BPL=75% speed, 6 BPL = 50%, hires 3 BPL = 50%, hires 4 BPL = 0%), but only during the time bitplane DMA is used. So a 5 BPL 320x256 scrolling screen has the CPU running at ~75% speed of each visible scan line and at 100% for the remainder, or roughly 80% overall.

Memory speed for the CPU is further impacted by Audio, Disk, Copper, Sprite and Blitter DMA. Which I haven't included for clarity.

And what is speed of (real) FAST RAM in Amiga 500?

Fast RAM on an A500 always runs at full speed for the CPU, or ~3.5MB/s regardless of any custom chip usage. Note that this is more of a gain than might be thought, clever programming can keep the Blitter/Copper/etc busy while doing stuff with the CPU in Fast RAM. This can improve performance by quite a bit.

hm... Shifter in ST do not even use available 4MB/s but rather around 2MB/s for 32KB screen (320x200 in 16 color, 60Hz; and somewhere more for 640x400 mono @71Hz on SM124) - rest of available memory cycle is used for memory refreshing. Someone claim that Atari use RAM outside manufacture specification to achieve this speed (4MB/s for CPU and 4MB/s for Shifter) so this additional refreshing cycles are necessary because of this.
But, what prohibit in ST design to have e.g. 32colors (5 bitplanes)? There is enough bandwidth for this...

The same that prohibits the Amiga OCS design from having 8 BPL screenmodes: design time decisions.

My guess is that Atari didn't want to spend the time and money needed to create a better graphics chip - the one they had was significantly better than the 8 bit chips and consumer level PC hardware as it was and the Amiga wasn't on the market yet.

[zero]

Thanks for the great explanation roondar.

I think this shows why hardwaresprites are so great. Any kind of blitter object or CPU soft sprite uses lots of scarce memory bandwidth. Save the background bitmap if needed, read the sprite bitmap, write the sprite bitmap, then next frame restore the background. Masses of copying and register programming.

With hardware sprites you write a few registers and that's it. You loose some memory access cycles for sprite DMA, but only a fraction as many as blitter/soft sprites.

Amiga hardware sprites are quite limited. Games try to make use of them anyway... For example, in Sidewinder the player's bullets are all one sprite, re-used over and over since they can't overlap vertically. A few copper instructions and 68k memory writes instead of multiple blitter operations. I don't know if it even uses sprite DMA... Since the bullets are the same for ever scan line, sprite DMA could be turned off and the buffer registers pre-loaded.

[roondar]

Originally Posted by zero

Thanks for the great explanation roondar.

I think this shows why hardwaresprites are so great. Any kind of blitter object or CPU soft sprite uses lots of scarce memory bandwidth. Save the background bitmap if needed, read the sprite bitmap, write the sprite bitmap, then next frame restore the background. Masses of copying and register programming.

With hardware sprites you write a few registers and that's it. You loose some memory access cycles for sprite DMA, but only a fraction as many as blitter/soft sprites.

Hardware sprites are awesome to have (for the time). Systems having hardware sprites vastly outperformed those without just about all the time. Sometimes even beating systems that where released years later (but without sprite hardware). Something like the humble C64 (1982, <1Mhz CPU) kept being relevant all the way to the early 90's, in large part due to it's sprite and scrolling hardware allowing it to do games quite well and without any of the slowdown usually seen on homecomputers.

A lot of C64 games clearly run better than their Atari ST/Amiga counterparts (mainly because those tended to be straight ST games, not using Amiga sprite/bob hardware).

The same can be seen in the PC-Engine: on paper it should be trounced by the Amiga (much slower CPU, less colours, etc). But it's hardware sprites meant it could compete or outperform the Amiga fairly easily.

Amiga hardware sprites are quite limited. Games try to make use of them anyway... For example, in Sidewinder the player's bullets are all one sprite, re-used over and over since they can't overlap vertically. A few copper instructions and 68k memory writes instead of multiple blitter operations. I don't know if it even uses sprite DMA... Since the bullets are the same for ever scan line, sprite DMA could be turned off and the buffer registers pre-loaded.

Amiga sprites do have a bit of a bad reputation. They are awesome for displaying bullets, their built-in multiplexing means that you can create a ton of bullets on screen with very little overhead. They can also be used for quite a few neat tricks, such as extra background layers, starfields, etc. And that's not looking at AGA, because AGA sprites are really quite nice.

They are also much, much quicker than the Blitter is.

Basically, when programming an Amiga game, it always pays to check if you can't use sprites instead of bobs for objects. It's basically a 'free' performance boost.

[zero]

Originally Posted by roondar

The same can be seen in the PC-Engine: on paper it should be trounced by the Amiga (much slower CPU, less colours, etc). But it's hardware sprites meant it could compete or outperform the Amiga fairly easily.

I've been thinking about this a bit lately, having recently acquired a PC-Engine. It's CPU runs at 7.16MHz in fast mode, and it's a 65C02 variant with a built in MMU and sound hardware.

It's actually very competitive with the 68000 for games. It has the fast zero-page so lots of "registers". The PC-Engine design reduces contention between the CPU and other hardware for memory access slots.

The main thing it lacks is multiplication hardware, although the 68000's isn't particularly fast either. But for most 2D games that doesn't really matter, they tend not to use multiply instructions much.

But yeah, having those sprites makes it very competitive.

Amiga sprites do have a bit of a bad reputation. They are awesome for displaying bullets, their built-in multiplexing means that you can create a ton of bullets on screen with very little overhead.

Only if the bullets move vertically though ;-)

Or I guess you could re-use a single sprite on a scanline if the bullets are spaced far enough apart and you can sacrifice the copper cycles.

Basically, when programming an Amiga game, it always pays to check if you can't use sprites instead of bobs for objects. It's basically a 'free' performance boost.

I think you have to really plan ahead, which is why doing conversions can be so tricky. If you design the game to make maximum use of sprites and other hardware features/tricks it can look amazing. It's not like systems with loads of sprites though, where you don't really have to think much beyond "how many can I get per scanline" and "how do I keep them all moving".

[zero]

Video of the ST port posted:

[ Show youtube player ]

Can someone explain how this is possible? I don't know a huge amount about the ST, but there seems to be a lot of sprites and movement on screen at once there.

[sandruzzo]

Originally Posted by zero

Video of the ST port posted:

[ Show youtube player ]

Can someone explain how this is possible? I don't know a huge amount about the ST, but there seems to be a lot of sprites and movement on screen at once there.

Shit! We can do it on Amiga!

[AnimaInCorpore]

Originally Posted by zero

Can someone explain how this is possible? I don't know a huge amount about the ST, but there seems to be a lot of sprites and movement on screen at once there.

The emulator runs at 32 MHz so it doesn't represent a real machine.

[dlfrsilver]

OK, basically, Anima explained that this is just a test with sprites and background.

But the actual specs are just too high : 32mhz clocked CPU + 14mb of ram.

This even in 16 colors !

his goal is to make the game fits with 4mb of ram and 8mhz CPU clock.

[dlfrsilver]

Originally Posted by sandruzzo

Shit! We can do it on Amiga!

Well if anima agrees to lend you the arcade code modified, why not ?

[zero]

In 16 colours it might be possible on Amiga, yeah... Ideally with more RAM and a faster CPU as well. I think fast RAM will be necessary just to get enough CPU cycles to run the arcade logic code.