Arcade / Console --> Amiga conversion discussions

[zero]

Originally Posted by dlfrsilver

The problem Anima stands with the bitplans number.... CPS games use something like 8 bitplans in Amiga mode (considering that the CPS systems are planar to start with).

The CPS systems are not planar. The backgrounds and sprites are all tile based, with independent colour palettes that have 16 bits per colour.

If you go to 256 colours on the Amiga it will probably be about the same amount of data, but your game will be very slow.

If the arcade needs 16mb (Ghouls'n'ghosts to name it), with only 16 colors, you lower the bar for the graphics storage.

The ROM files are about 4MB. Maybe you are confusing your units... 2MB of graphic data would be 16Mb.

The Megadrive version is only 5 megabit, which is actually 0.625 megabytes. In other words, the entire Megadrive version would fit into a 1MB RAM Amiga with lots of room to spare.

In any case, with loading between levels it should be no problem, especially after all the graphics and sound are reduced to Amiga level. 512k should be more than adequate.

For Ghouls'n'Ghosts STE, you will need 4mb of ram even with 16 colors for the whole game, also considering the amount of sprite frames and the diversity of the tiles for the whole game.

Yes, because it's using the arcade code that requires all assets to be in RAM all the time.

[AnimaInCorpore]

Originally Posted by zero

If you go to 256 colours on the Amiga it will probably be about the same amount of data, but your game will be very slow.

The arcade tiled data is stored in a format where a pixel is packed into four bits. This results in 16 colours (i.e. 15 + transparency) which is the same amount of memory you need for a 16 colour planar display version.

Converting all of them to 256 planar colours doubles the memory consumption because you need eight bits per pixel and you have still less colours compared to the arcade machine. You also have to add the horizontal flipped versions and a mask (which is another additional plane).

And I didn't even mentioned the sprites which can have different palettes.

[dlfrsilver]

Originally Posted by zero

The CPS systems are not planar. The backgrounds and sprites are all tile based, with independent colour palettes that have 16 bits per colour.

You're mixing up 2 things : the kind of display, and the graphic display type.

1. The CPS systems ARE planar, just check the mame driver !

2. The CPS systems are based on the graphic system used on the X68000 (it's the source hardware it's based on).

The CPS1 hardware use 192 palettes of 16 colors. All those palettes are used for the sprites, backgrounds and foregrounds.

If you go to 256 colours on the Amiga it will probably be about the same amount of data, but your game will be very slow.

Very slow because the AGA system is weak The CPS graphics chip are clocked at 16mhz..... which is _VERY_ fast.

The ROM files are about 4MB. Maybe you are confusing your units... 2MB of graphic data would be 16Mb.

You are mixing up your units. I'm talking in megabytes, not megabits !

The arcade code roms are 1024kb, so 1megabyte !

The Megadrive version is only 5 megabit, which is actually 0.625 megabytes. In other words, the entire Megadrive version would fit into a 1MB RAM Amiga with lots of room to spare.

Both systems are too different. The Amiga would just slowdown to build everything back in ram.

A 512kb game on Megadrive would take at least 2 amiga disks !

In any case, with loading between levels it should be no problem, especially after all the graphics and sound are reduced to Amiga level. 512k should be more than adequate.

512k is just not enough, you're dreaming a bit i'm afraid

Yes, because it's using the arcade code that requires all assets to be in RAM all the time.

Yes that's because the code is unified. In order to lower the ram requirements, multiload ingame would be needed, and splitting all the arcade code.

the X68000 version use only 2mb of ram, but at the price of splitting the whole game per level and sprites.

[zero]

Right, where did you get "16mb" from what? Is that mega BITS or mega BYTES?

The CPS display is NOT planar. The sprite and tile data is stored in a planar format, but the display is tile and layer based with independent palettes. The display is made up of tile maps and sprites. The point here is that you can't simply convert that to a 256 colour planar display.

Also, remember that the 1MB of code is for the arcade hardware... Which has a second Z80 CPU to run sound, so you can chuck all that out and replace it with a light weight Amiga MOD + sound effects player. And ditch most of the background animation, because the blitter isn't going to be able to animate all those trees in the first level fast enough...

[dlfrsilver]

Originally Posted by zero

Right, where did you get "16mb" from what? Is that mega BITS or mega BYTES?

Ghouls'n'Ghosts, arcade version, when you emulate it on a PC, takes 16 mega_bytes_ of ram !

Final fight takes 12mb of ram, Strider 16mb of ram, Cadillac and dinosaurs 20mb of ram, etc etc.....

Megabits were only used by the japanese. The US/EURO system is the byte, kilobyte, megabyte, terabyte.

The CPS display is NOT planar. The sprite and tile data is stored in a planar format, but the display is tile and layer based with independent palettes. The display is made up of tile maps and sprites. The point here is that you can't simply convert that to a 256 colour planar display.

Ok, ok, let me enlight you : mame doesn't allow the sprite and tilemap display of games that are not PLANAR !

Any game like Shinobi, shadow dancer or any other sega system 16,18,24 just won't display the tilemaps nor the sprites !

Why ? Because mame doesn't support the chunky/bitmap formats !

the Sega systems are MIXING planar assets with bitmap chunky assets

If the CPS systems were not planar, you just should not be able to view the tiles and the sprites inside mame.

In order to detail things better, the Amiga is a planar bitmap display computer, and the CPS system is planar tile display system.

but both are planar. the palette colors attribution has nothing to do with the planar rendering.

Also, remember that the 1MB of code is for the arcade hardware...

that's exactly what i was saying above ! you just didn't read what i wrote

Which has a second Z80 CPU to run sound, so you can chuck all that out and replace it with a light weight Amiga MOD + sound effects player.

the CPS1 system has only 1 Z80, and not 2. the main CPU is a 68000, clocked either 10 or 12mhz.

But yes, it would need a driver (a specific one able to deal with music and sfx at the same time.)

And ditch most of the background animation, because the blitter isn't going to be able to animate all those trees in the first level fast enough...

it's not exactly blitter based, it's display based (VBL based). the CPS hardware doesn't work like an Amiga.

the 68000 here suffers the most, because it has to send the tile metadata to the graphics chips for display or refresh.

[kovacm]

Originally Posted by zero

Right, where did you get "16mb" from what? Is that mega BITS or mega BYTES?

The CPS display is NOT planar. The sprite and tile data is stored in a planar format, but the display is tile and layer based with independent palettes. The display is made up of tile maps and sprites. The point here is that you can't simply convert that to a 256 colour planar display.

I always wonder how arcade games has such nice graphics with so few KB of RAM (CPS: 64 KB WORK RAM + 192 KB VRAM)?
So how does CPS work? Does it have traditional buffer like ST and Amiga (bitplanes in memory which are read by hardware that generate signal for TV or monitor?) or hardware for generating video signal read data of sprites directly from ROM at exact position while TV beam draw image?
Or if you copy all sprites, background... from ROM to frame buffer - how fast you need to read and write data from ROM to frame buffer?? It looks like you need some serious bandwidth? I am really puzzled by hardware of Arcade games...

[dlfrsilver]

Originally Posted by kovacm

I always wonder how arcade games has such nice graphics with so few KB of RAM (CPS: 64 KB WORK RAM + 192 KB VRAM)?

this is special ram, used as hyperfast cache. Arcade games are rom based, everything is already in place to be executed.

The real memory size is the whole game size * 2

Ghouls'n'Ghosts use 8mb of VRAM, with double buffer, so 16mb in total.

So how does CPS work? Does it have traditional buffer like ST and Amiga (bitplanes in memory which are read by hardware that generate signal for TV or monitor?) or hardware for generating video signal read data of sprites directly from ROM at exact position while TV beam draw image?

the CPS system is basically a system where the program, the sound and the graphics are all hardware assisted.

The program has hardware functions that are releving the CPU for calculations for example (not all board, only some like Varth), as well as primary rotations on sprites (as can be seen in Final fight, with the 1st level boss, it has no frames from rotations, those are performed directly by the hardware). The palettes systems is also hardware assisted, you just need to feed the registers, and the hardware take care of them.

the graphic assets are a sort of big database of graphics. The 68000 is handling a tons of tile metadata that are 'word' based. his role is to send them/feed them to the graphics chips, which in turn are displaying the tiles and refreshing them.

The CPS system is using tiles, but the backgrounds are made of tiles printing on 3 independent playfields, that are all planar, and the system only display the part your currently moving on.

It's very different from the ST or the Amiga.

Or if you copy all sprites, background... from ROM to frame buffer - how fast you need to read and write data from ROM to frame buffer?? It looks like you need some serious bandwidth? I am really puzzled by hardware of Arcade games...

The system needs to know the X and Y position inside the playfield system, as well as if the sprite has to be flipped or not (just by 0 or 1 lol), as well as the X and Y positions of each playfields, and those variables are updated each VBL.

there is no "i pick from rom and copy to frame buffer". the system knows where to pick the tiles thanks to the tile metadatas uploaded by 68000 to the graphics chips, it then mix-up the palette, and it's printed directly on screen (TV or arcade monitor).

the CPS system is a tile animation hardware engine. its root are what the cartoon designers used to do for japan animes.

Multiple layers of backgrounds, characters to position, etc etc.

that's why the games looks like so much to animated cartoons

[zero]

Originally Posted by dlfrsilver

Ghouls'n'Ghosts, arcade version, when you emulate it on a PC, takes 16 mega_bytes_ of ram !

When you _emulate_ it

If the CPS systems were not planar, you just should not be able to view the tiles and the sprites inside mame.

The sprite/tile graphic data is planar, the display is NOT! The display is not generated from a planar bitmap, it is generated from a tile map and sprites.

That's extremely important to understand because it has huge implications for the number of on-screen colours, scrolling, animation etc.

In order to detail things better, the Amiga is a planar bitmap display computer, and the CPS system is planar tile display system.

You almost get it... But the key thing to understand here is that the display is not any kind of bitmap, you can't blit stuff onto it. In fact I'm not sure you can even display graphic data from RAM on that system, I'd have to check.

The tiles are not rendered to a bitmap, they are read and displayed using DMA on the fly similar to how the Amiga reads bitplane data just as it is needed.

the CPS1 system has only 1 Z80, and not 2. the main CPU is a 68000, clocked either 10 or 12mhz.

That's what I said!

But yes, it would need a driver (a specific one able to deal with music and sfx at the same time.)

Realistically you would need to re-compose the music down to 2 or 3 channels and maybe drop some of the sound effects simply because you wouldn't have enough channels.

I suggested a way to double up channels to get 8 virtual channels using the blitter, but with everything else there won't be any free cycles for it.

[zero]

Originally Posted by kovacm

I always wonder how arcade games has such nice graphics with so few KB of RAM (CPS: 64 KB WORK RAM + 192 KB VRAM)?
So how does CPS work? Does it have traditional buffer like ST and Amiga (bitplanes in memory which are read by hardware that generate signal for TV or monitor?) or hardware for generating video signal read data of sprites directly from ROM at exact position while TV beam draw image?
Or if you copy all sprites, background... from ROM to frame buffer - how fast you need to read and write data from ROM to frame buffer?? It looks like you need some serious bandwidth? I am really puzzled by hardware of Arcade games...

All the bitmaps are in ROM, and read directly by the graphics hardware. There is no frame buffer at all, as you speculate everything is read directly from ROM as the TV beam draws the image.

The only VRAM needed is for the tile map and sprites. The basic tile map is also in ROM, but by having it in RAM you can do animated backgrounds like the trees blowing in the wind on level 1. Typically a lot of the tile maps will be in ROM with just one layer of animated tiles, so you don't need much RAM for this.

Sound is similar. All samples in ROM, all music scores in ROM, all you need in RAM is a few pointers. The CPS has a second CPU, a Z80, just for sound which has its own 2kB of RAM anyway, so the main 68000 literally just sends it one command like "play sample X" or "play music track X".

That means that the 64k of work RAM is really just for the game logic, and 64k is actually a lot. The NES had 2k of similar work RAM, and could fit pretty big games like Mario 3 in there.

[dlfrsilver]

The sprite/tile graphic data is planar, the display is NOT! The display is not generated from a planar bitmap, it is generated from a tile map and sprites.

Each tilemap is a virtual area 512x512, 1024x1024 and 2048x2048.

Those zones are Planar. The only thing that differs, is that it's a planar display without colors limitations !

If you basically mean that it's a PC like display, you're wrong !

The sega megadrive for instance is not using a planar display, it's a chunky tiled display !

That's extremely important to understand because it has huge implications for the number of on-screen colours, scrolling, animation etc.

It has none. You're actually mixing up what the arcade hardware is and what a computer hardware is (the Amiga in occurence !).

You almost get it... But the key thing to understand here is that the display is not any kind of bitmap, you can't blit stuff onto it. In fact I'm not sure you can even display graphic data from RAM on that system, I'd have to check.

Look, i'm not only talking about the CPS system, i've put my hands inside the code program of many games, and i have even crawled inside the game tiles metadatas !

I have extracted some sprites straight from Final Fight from Instance, so i know what i'm talking about !

The hardware doesn't give a fuck about the amount of bitplanes needed to display a sprite or tilemaps for levels ! If it need 5 BPL, it will use 5BPL, 8BPL if 8BPL is needed and so on !

Why and how ? because each tile is seperately managed as a seperated planar object !

Doing the same thing on Amiga would require considering what Anima shown something like 24 BPL for the whole game, as this game use for the whole game 1270 unique colors !

The tiles are not rendered to a bitmap, they are read and displayed using DMA on the fly similar to how the Amiga reads bitplane data just as it is needed.

nope ! That's not how it works !

The Arcade code is building on startup the 3 tilemap layers, setting the color hardware registers, etc etc.

Each layer is a virtual space of a defined and limited size. the tiles are printed inside each tilemap thanks to the indications given by the tiles metadata inside the 68000 program.

There is no "hop, i trigger the DMA and hop i print on screen".

The roadmap is :

68000 is access a data space (tile metadata) inside the program code.
It then parse the amount of metadata size and then feed the graphics chips registers with them. Thanks to the protected GAL on each board of the hardware, this one knows exactly where can be found each type of tiles.
Once the graphics chip are processing and displaying the tiles, the 68000 is running the game logic during the whole VBL.

That's what a CPS engineers (read game programmer) explained.

The CPS hardware is doing parallel processing. Once the 68000 has fed the graphic system, the graphic system is doing its job, and the 68000 is not stopped, it continues to run the game logic !

That's another difficulty if you want to convert a CPS game on a computer with no hardware tile assistance.

the CPS system has some common points with the Sega Megadrive, with many differences however.

[dlfrsilver]

double post

[zero]

dlfrsilver, you are hopelessly confused. You are arguing about things you seem to agree with me on.

Originally Posted by dlfrsilver

The Arcade code is building on startup the 3 tilemap layers, setting the color hardware registers, etc etc.

What do you mean "building"?

There is no "hop, i trigger the DMA and hop i print on screen".

That's exactly what happens. Every scanline the graphics hardware uses DMA to fetch tile and sprite data, and then draws the scanline pixel by pixel as the video signal is being generated.

If there is any kind of cache bitmap for the scanline, it must be internal to the graphics hardware and certainly is not memory mapped in the main CPS memory space.

[kovacm]

@DamienD

I think that it is pretty important (and for Rygar conversion thread) to understand how Arcade work and how Amiga work so please make another topic.

---
@zero
So 68000 in CPS never read graphics or sound data from ROM but only "order" to video and sound hardware what and how they should draw/play. This is somehow similar to e.g. how Amigas 68000 setting custom chips (blitter, agnus, paula...)?

192 KB VRAM in CPS is used to compose background layer?

Anyway, quite clever system how much did cost ROM vs RAM back in 80s and 90s?

I found how Metal Slug for NeoGeo compose display (somebody spread graphics to layers): [ Show youtube player ] - but I am not sure how much NeoGeo is different from CPS...

[kovacm]

Originally Posted by dlfrsilver

this is special ram, used as hyperfast cache. Arcade games are rom based, everything is already in place to be executed.

The real memory size is the whole game size * 2

Ghouls'n'Ghosts use 8mb of VRAM, with double buffer, so 16mb in total.

I do not understand.

8MB of VRAM??!
VRAM is RAM. CPS does not have 8MB of any RAM... ?!? What you mean by this?

---
and please write MB - for mega bytes
and Mb - for mega bits (8 time smaller)

[sandruzzo]

what about doing a simple test on amiga to see what i could be possible?

[AnimaInCorpore]

Originally Posted by kovacm

I found how Metal Slug for NeoGeo compose display (somebody spread graphics to layers): [ Show youtube player ] - but I am not sure how much NeoGeo is different from CPS...

Contrary to the CPS (and almost all other tile based systems) the Neo Geo system has no background layers. Those need to be composed from sprites which is rather easy due to a certain flag in the sprite control data. Neo Geo sprites are always 16 pixels wide and up to 512 pixels high and the system is able to display 381 of them simultaneously.

[zero]

Originally Posted by kovacm

@zero
So 68000 in CPS never read graphics or sound data from ROM but only "order" to video and sound hardware what and how they should draw/play. This is somehow similar to e.g. how Amigas 68000 setting custom chips (blitter, agnus, paula...)?

Yes, that's right. It's like how once you have copied graphic data for a sprite into RAM on the Amiga, all you need to do to display it is to set the sprite hardware registers up with a pointer to the data and where to display it. The hardware then reads and displays that data itself, the CPU doesn't have to manually copy it to the screen bitmap.

It's the same with sound. You just tell the hardware which bit of RAM to read the sample data from, what pitch and how long to play it for, and it does all the actual reading of data for you.

The main difference with the CPS hardware is that all the graphics and sound are in ROM. There is no need to copy them to RAM, they can be read directly from ROM by the graphics hardware. On the Amiga you have to load the graphics from disk into RAM, so you need a lot of RAM.

192 KB VRAM in CPS is used to compose background layer?

It doesn't use bitmaps if that's what you mean. The background layers are tile maps, which are stored in VRAM. So rather than actual graphics, it's just a 2D array of tile numbers. The hardware knows where in ROM to look for each tile number.

Anyway, quite clever system how much did cost ROM vs RAM back in 80s and 90s?

ROM was a lot cheaper. In arcade systems cost wasn't such a big issue though. The ROM is more like a floppy disk on the Amiga - most games don't write to floppy, it's effectively read-only.

I found how Metal Slug for NeoGeo compose display (somebody spread graphics to layers): [ Show youtube player ] - but I am not sure how much NeoGeo is different from CPS...

It's similar but more advanced. On the NeoGeo there are no background layers, you just use sprites to make the background. And it has a few more features like sprite scaling and more of them compared to CPS. And it supports much larger ROMs.

[zero]

Originally Posted by kovacm

8MB of VRAM??!
VRAM is RAM. CPS does not have 8MB of any RAM... ?!? What you mean by this?

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).

[kovacm]

Thanks, now things are much more clear now.

Just one more thing:

It doesn't use bitmaps if that's what you mean. The background layers are tile maps, which are stored in VRAM. So rather than actual graphics, it's just a 2D array of tile numbers. The hardware knows where in ROM to look for each tile number.

You insist that that CPS does not use planar bitmaps. Can we clear how background tiles work?
---
Now I understand that RAM only hold ID of tile and actual data (pixels) are in ROM.

If every sprite and tile has one 16 color palette so every pixel is stored as 4bit value of palette entry. Also every sprite/tile need to store information which palette he use (one byte is enough if there is 192 different palettes).

So what happens if you need to display background tile (e.g. 16x16px) but from 4th pixel? Player move to right for 3 pixel and entire background should now be displayed shifter for 3 pixels. How hardware do this?
It simple know that should start to read from 4th pixel and after 13 pixels to wrap and read (display) 1st pixel in tile?
I mean there is no need to rotating bits in byte (or more bytes, like in case of ST) on bitplanes (or similar technique) like in ST or Amiga?

[roondar]

Originally Posted by kovacm

Thanks, now things are much more clear now.

Just one more thing:

You insist that that CPS does not use planar bitmaps. Can we clear how background tiles work?
---
Now I understand that RAM only hold ID of tile and actual data (pixels) are in ROM.

If every sprite and tile has one 16 color palette so every pixel is stored as 4bit value of palette entry. Also every sprite/tile need to store information which palette he use (one byte is enough if there is 192 different palettes).

So what happens if you need to display background tile (e.g. 16x16px) but from 4th pixel? Player move to right for 3 pixel and entire background should now be displayed shifter for 3 pixels. How hardware do this?
It simple know that should start to read from 4th pixel and after 13 pixels to wrap and read (display) 1st pixel in tile?
I mean there is no need to rotating bits in byte (or more bytes, like in case of ST) on bitplanes (or similar technique) like in ST or Amiga?

Well, most tile based systems have a register that allows you to shift the display by a number of pixels. Then the hardware just fetches it's graphics as normal, but draws them shifted.

I don't know exactly how the CPS-1 hardware does this, but I presume it's similar to how other tile based systems (such as the C64, PC-Engine, MegaDrive/Genesis and SNES) do it: either hide the pixels to draw behind a border, or fetch more columns and rows than are visible and offset them.

This is actually fairly similar to how the Amiga does barrel-shifted scrolling, except the source of the pixels is different (tile ROM/RAM vs bitmap RAM). What might help is to decouple the tiles from drawn pixels in your mind. It really doesn't matter for a display chip what the source of the pixels is. As long as it knows what pixels come next it can draw them and if it has shift circuity, it can shift them while doing so.