Any C2P experts here?

[oRBIT]

I'm thinking if rewriting the gfxdriver in A/NES, my NES emulator for classic AmigaOS, and make use of chunky graphics instead of planar. There are several benefits but the c2p conversion on AGA/ECS systems is an obvious drawback.
I'd probably be using a 256x240x5 screen. A c2p using delta-conversion would probably benefit quite alot due to the nature of the graphics.
I am however no c2p expert myself and the last time I checked, the "market" of public c2p's using deltabuffers were quite limited.

So my first question is..
What kind of speed do you think I can expect on 68030/50 or 68060/50 using worst case c2p scenarios (full screen conversion?)
The emulation itself is using *alot* of CPU time and I wonder if it's worth the effort of implementing a chunky gfxdriver for classic Amiga-systems.

My second question is..
Could a c2p be customized for the kind of graphics NES uses to optimize performance? The NES gfx is tile based (8x8 pixels)with heavy restrictions on the amount colours to be used on such a tile.

Thanks in advance

[Kalms]

I'll just take 68060 as an example.

a full c2p conversion (without delta etc) need to do 3 things:

1) read 256x240 bytes = 60kB of data from fastmem
2) transform it
3) write 256x240x5 bits = 37.5kB of data to chipmem

Step 1 and 3 can not be done in parallel.
Step 2 can mostly be done in parallel with step 1 & step 3.

Step 1 takes perhaps 20 scanlines.
Step 2 takes perhaps 50 scanlines.
Step 3 takes perhaps 125 scanlines.
[the figures above are rough estimates.]


Thus you can expect the full conversion to take 20+125=145 scanlines. The CPU's memory bus will be busy all the time.
The CPU will be doing actual processing during about 50 of those 145 scanlines. Rest of the time is the CPU stalling waiting for the bus interface to finish previous operations.

The above points to the fact that what would make the most difference to you would be to reduce the amount of chipmem writes. Extra computations or extra fastmem accesses (for instance, by doing delta c2p) traded against less chipmem writes might help.
However then a full conversion will be slightly slower than the naive approach.

Your call.

[Cosmos]

@Kalms

Please, are you ok to put in the graphics.library your fast c2p for :

- 000/010
- 020
- 030
- 040/060


For coders, reinventing the wheel each times, it's not funny !

[Kalms]

which routines are you thinking of?

generally, any program that runs on 000/010 requires the c2p conversion integrated into the rendering code to reach high enough framerates.

As for 020/030, they can use the same routine, and 040/060 usually can share routine as well with no drawbacks.

If you were referring to some delta c2p, then sure - but the question at hand is whether or not a delta c2p would be useful (and at what stage the delta comparison should be performed).

[oRBIT]

@Kalms
Can you (or anyone else perhaps) point to a public c2p that's capable of doing a 256x240x5 (but configurable to 8) conversion?
Everything on Aminet feels pretty ancient sadly.

Or even better, anyone up for the task in helping with a customized c2p?

[watertonian]

Originally Posted by oRBIT

My second question is..
Could a c2p be customized for the kind of graphics NES uses to optimize performance? The NES gfx is tile based (8x8 pixels)with heavy restrictions on the amount colours to be used on such a tile.

Snipped the first ??, as I have no idea how to speed that up. Though I think you hit the jackpot on the 2nd question. If the NES can only use 8x8 tiles, at 16 or 32 colors, you might be able to pre-convert the tile data to planar, and just use the blitter to move them about. This would require a bit more ram, but I'm guessing not as much as a c2p dump of a whole screen, though that would depend on how many "tiles" are used. The only thing I would worry about is how NES games store tiles, if its not standard, it might be problematic from game to game. Though it might be possible to do an on-the-fly conversion as tiles are used, with the option of caching the converted data for later use if the tile is called again (requiring some sort of MMU table or custom alternative).

[oRBIT]

The NES actually uses planar graphics but as I've discovered, it's still a pain to use on the Amiga due to several reasons.
NES background graphics consists of 4 planes (sort of). Two planes with actual graphics and two more ones (called attributetable)that just selects the palette.
The attributetable is 64 bytes and each byte looks like this:
%AABBCCDD
AA represents a 16x16 block in the upperleft corner with upper color bits AA.
BB represents the lowerleft 16x16 block
CC -:- upper right 16x16 block
DD -:- lower right
So each byte describes the palette for a 32x32 pixel block.

Which means, the attribute bits changes more rarely and perhaps could be handled in a separate way in a clever c2p?

[Kalms]

Unpacking attribute table with lazy evaluation, 68020+/AGA style:

do it 100% on the CPU side.

char currentAttributeTable[64] = ...;
char previousAttributeTable[64] = ...;

for (i = 0; i < 64; i++)
{
	if (currentAttributeTable[i] != previousAttributeTable[i])
	{
		write 32x32 pixels x 2 bitplanes to chipmem, with currentAttributeTable[i] as the source info
	}
}

work to be done:
1) 64*2 = 128 bytes of fastmem reads, regardless of number of changes
2) for every byte that has changed, generate pixelmasks to write to chipmem - should take not more than a bunch of cycles
3) for every byte that has changed, write 32*4*2 = 256 bytes to chipmem

If there is a significant numbeer of updates, then 90%+ of the time will be spent waiting for chipwrites to complete. You could actually build a copperlist (or use a blitter interrupt) and get the blitter to perform the memory writes. This would work out because the amount of info that you need to transfer fast->chip is vastly smaller than the amount of chipmem writing that needs to be done.

[hit]

Originally Posted by oRBIT

@Kalms
Can you (or anyone else perhaps) point to a public c2p that's capable of doing a 256x240x5 (but configurable to 8) conversion?
Everything on Aminet feels pretty ancient sadly.

Or even better, anyone up for the task in helping with a customized c2p?

not exactly sure where, but i guess here at eab-board, kalms posted his collection. again in the zone now (c2p_kalmsc2p.lha) - and i have no clue, if it fits your request

@Kalms: is it ok posting it again?

[Kalms]

sure, or just google it - http://www.google.com/#hl=en&q=kalmsc2p.lha

you probably want c2p1x1_5_c5_030.s / c2p1x1_5_c5_060.s for starters.

[hit]

Originally Posted by Kalms

sure, or just google it

ok

[Kalms]

now also available at http://unitedstatesofamiga.googlecode.com/ (and it ought to survive for a while over there)

[oRBIT]

Thanks for that. Worked great. However, I do miss some c2p's that implements deltabuffers. :-)

[Kalms]

Try it yourself first. Use an existing routine to C2P convert fast->fast, then do a delta copy fast->chip. It's going to be a tad slower than a C2P with deltacopy built in, but not all that bad.

[NovaCoder]

Originally Posted by Cosmos

@Kalms

Please, are you ok to put in the graphics.library your fast c2p for :

- 000/010
- 020
- 030
- 040/060


For coders, reinventing the wheel each times, it's not funny !

BlazeWCP patches the AmigaOS chunky functions already. What would be a good idea is to include BlaseWCP (or an improved CPU targeted version) into graphics.library (one less patch).

[oRBIT]

@Kalms:
I'm having issues with, what I suspect, your c2p:
Check out this package I've done:
http://dl.dropbox.com/u/2590713/C2PIssue.lha
There are three files:
SMB.Chunky = 256x240 Chunky screen (source)
C2P_Result = Bitplane image converted by your c2p. Saved as IFF24 by artpro
Chunkysource = SMB.Chunky converted to IFF24 by Artpro using Chunky loader

Don't mind the generally buggy graphics. Check out the "chunkysource" file. There's a line of dots where Mario usually stands. The dots are like 1,0,1,0,1,0,1,0.
Now check out the C2P_Result. The dots doesn't look the same. Some kind of smearing stuff and I don't understand why.
I've traced my code but at the moment it looks something is strange with the c2p conversion. I'm using the c2p1x1_5_c5_060.s code.

[StingRay]

Looks like that is indeed a bug in the 5bpl c2p, when using the 6bpl c2p everything looks fine. May do some debugging later.

[oRBIT]

@Stingray: Thanks for verifying that. I thought I was going nuts.

[Kalms]

Just a thought -- those white dots, are those color value 31 or 255? If you have pixels with color value higher than 31 in the buffer, then the 5bpl c2p will produce such smearing.

[oRBIT]

@Kalms: Nope, they have value $1D.