EHB, HAM6 and HAM8 demonstration pictures?

[pandy71]

Originally Posted by Thorham

I'm pretty sure the copper can change one color every 8 lowres pixels if the screen depth isn't too high.

Copper require 2 cycles (first word instruction, second word data) - CPU theoretically can do this twice faster. Perhaps Meynaf is able to confirm (or not) this.

Originally Posted by Thorham

All that's needed is a viewer and a conversion step from the ST format to Amiga. Both seem pretty trivial to me.

Great statement - i will be happy to see such converter and viewer.

[kovacm]

Originally Posted by vulture

Isn't it on a Falcon?

no, for ST: http://www.atari-forum.com/viewtopic...l+slug#p221071

it is only scrolling graphics without gameplay!

[Thorham]

Originally Posted by pandy71

Copper require 2 cycles (first word instruction, second word data) - CPU theoretically can do this twice faster. Perhaps Meynaf is able to confirm (or not) this.

Does that mean you can change one color evey 4 lowres pixels? Anyway, to match the Atari software I think you only need one colore per 8 lowres pixels. Doing this with the copper is also better because it doesn't strain the CPU as much.

Originally Posted by pandy71

Great statement - i will be happy to see such converter and viewer.

Well, it's hardly rocket science.

[kovacm]

Originally Posted by Thorham

All that's needed is a viewer and a conversion step from the ST format to Amiga. Both seem pretty trivial to me.

yes, you could use DML software...
...

Pandy really have a point in this thread... it is something that I always repeat: ST programers are "better" since they "count" cycles to achieve something and they try really hard.

another problem with Amiga users is attitude: "I mean, you make it sound like the Amiga technically couldn't achieve images like this, which is clearly wrong" (by britelite). It is narrative that repeats over and over... Amiga hardware is so superior that nobody can touch it (results: endless MegaDrive, SNES vs Amiga threads) but epilog is that results (demoscene products) on, so inferior, ST are really close to Amiga. Britelite even "cheat" in Eighteen just to show that Amiga (for uneducated users) can show more sprites than ST.

so, yes, you could use DML converter for this...

Originally Posted by Thorham

No, but I'm not sure I want to

you should.

[roondar]

Originally Posted by Thorham

Does that mean you can change one color evey 4 lowres pixels? Anyway, to match the Atari software I think you only need one colore per 8 lowres pixels. Doing this with the copper is also better because it doesn't strain the CPU as much.


Well, it's hardly rocket science.

The copper can definitely change one colour every 8 lowres pixels (assuming no more than 4 lowres/2 hires bitplanes shown). The 2 clocks per move is the amount of DMA bandwidth used, but since the copper can only access odd cycles, it actually takes 4 colour clocks to do a move = 8 lowres pixels.

[roondar]

Originally Posted by kovacm

yes, you could use DML software...
...

Pandy really have a point in this thread... it is something that I always repeat: ST programers are "better" since they "count" cycles to achieve something and they try really hard.

I am 100% certain that accomplished Amiga developers do exactly the same.

[meynaf]

Originally Posted by pandy71

Copper require 2 cycles (first word instruction, second word data) - CPU theoretically can do this twice faster. Perhaps Meynaf is able to confirm (or not) this.

Copper can do a change every 8 lowers pixels, cpu is twice faster (not sure for 68000, i don't remember movem timings).

If my memory doesn't betray me, the ST can do 3 full palette changes per scan line (= 48 colors).
I see no reason why the Amiga wouldn't be able to use the exact same tricks.

Originally Posted by roondar

I am 100% certain that accomplished Amiga developers do exactly the same.

Some accomplished Amiga developers were Atari developers before.
The Atari is a really good school for 68k coding.

[roondar]

Originally Posted by meynaf

Copper can do a change every 8 lowers pixels, cpu is twice faster (not sure for 68000, i don't remember movem timings).

I'm not too sure the 68000 is 2x as fast - movem writes or reads one word per 4 CPU cycles/long word per 8 cycles (plus between 8 and 14 cycles overhead per movem). If you count the reading as well as the writing, using it should take the same time as using the copper.

Originally Posted by meynaf

Some accomplished Amiga developers were Atari developers before.
The Atari is a really good school for 68k coding.

Of course. But that doesn't change that there are also accomplished Amiga developers who had no exposure to the Atari ST.

My point isn't to say that Atari ST developers are not good (in any way!), my point is that there are great Amiga developers as well. And personally, I don't feel that the chipset advantages mean you can really afford to be lazy. A bad piece of code on the Amiga will also create a bad result - blitter/copper or no.

[Thorham]

Whether or not the CPU is faster than the copper doesn't really matter because of the limited chipset register bandwidth. I've written the color registers with a 50mhz 68030, and you're still limited to one color per 8 lowres pixels.

[meynaf]

Originally Posted by roondar

I'm not too sure the 68000 is 2x as fast - movem writes or reads one word per 4 CPU cycles/long word per 8 cycles (plus between 8 and 14 cycles overhead per movem). If you count the reading as well as the writing, using it should take the same time as using the copper.

While some of this work can be performed during the horizontal blank (setting first color bank, preloading second), the 68000 is indeed probably not fast enough to do better than the copper.

Originally Posted by roondar

Of course. But that doesn't change that there are also accomplished Amiga developers who had no exposure to the Atari ST.

My point isn't to say that Atari ST developers are not good (in any way!), my point is that there are great Amiga developers as well. And personally, I don't feel that the chipset advantages mean you can really afford to be lazy. A bad piece of code on the Amiga will also create a bad result - blitter/copper or no.

We certainly agree on this.

Personnally I've found the Amiga to be more difficult to code on, but more rewarding, than the Atari.

Originally Posted by Thorham

Whether or not the CPU is faster than the copper doesn't really matter because of the limited chipset register bandwidth. I've written the color registers with a 50mhz 68030, and you're still limited to one color per 8 lowres pixels.

Are you sure it's 8 lowres and not 4 ?
A 50mhz 68030 can access chipmem every 28 clocks or so. That's around 1.7 Mhz, i.e. 4 lowres, 8 hires, 16 shres pixels.
This assumes, of course, that the cycles aren't used by anything else (like extra bitplanes).
If the limit is one color per 8 lowres pix, then the assumption that chipmem and chipset have same timing becomes wrong...

[Thorham]

Originally Posted by meynaf

Are you sure it's 8 lowres and not 4 ?

Yeah, I'm pretty sure. On Aga with double scan modes it's 16, I think.

I might be wrong, but it's pretty easy to verify. Just open a screen, and write $dff180 with alternating values in a loop. On a 68000 just unroll the loop. Shouldn't matter if you do it using an OS screen or a 'hit the hardware' screen.

Originally Posted by meynaf

If the limit is one color per 8 lowres pix, then the assumption that chipmem and chipset have same timing becomes wrong...

I thought that too, but it may indeed be incorrect.

[pandy71]

Color Clock is 3.58MHz and you can feed maximum 7.16MB over RGA/D bus - this is internal chipset design limitation (all except AGA where tricks similar to DDR are used to increase overall bandwidth) - some cycles may be available for CPU.
Above valid for NTSC, PAL is marginally slower ((4.43*4)/5).
And once again - problem is not in transfer speed (number of CLUT updates is identical on ST and Amiga as both systems suffer from same memory bandwidth limitations) but in quality of algorithms for color quantization and error distribution - on 2 bitplanes ST/STe is able to beat Amiga with 4 bitplanes and PCHG (as Dynamic Hires use CPU so it is more close to ST).
It is easy to verify - best Amiga graphic converter capable to do dynamic CLUT updates - HAMLab - is incapable to deliver same quality (perceived by observer) as http://www.leonik.net/dml/sec_pcs.py tool - we talking about lack of visible horizontal stripes (obvious problem with overloading CLUT changes - suboptimal color selection).
This is clearly visible on mentioned already 'elevation by The Electronic Knights' - those pictures are special class pictures very well suited to use Dynamic CLUT techniques (quite well balanced, plenty of luminance details but overall chrominance is very averaged - some contrasting chrominance is also well concentrated but at the same time not to diversified - all this lead to relatively small variance in color histogram, also color changes in vertical direction are almost penalty free).

[AnimaInCorpore]

Originally Posted by Thorham

No, but I'm not sure I want to

Some things to consider about improving the number of shades per colour channel.

Spectrum 512 images (Atari ST):






Spectrum 4k images (Atari STE):






Spectrum 29k images (Atari STE enhanced):






So there's clearly a difference viewing images with the flicker technique. You should have a look at them for sure.

[meynaf]

Images shown here don't flicker, but look more pixelated than on original screens. This applies for both Atari and Amiga images - HAM artifacts are less visible on CBM monitors because the relative big dot size makes some kind of natural antialias effect. Besides, video D/A characteristics aren't the same either.
So i'm not sure the comparisons are very meaningful (unless directly taking high quality photos of the screens themselves, of course).

[Thorham]

Originally Posted by AnimaInCorpore

So there's clearly a difference viewing images with the flicker technique. You should have a look at them for sure.

I can't, because I don't have an Atari ST Perhaps someone should just write a viewer

[AnimaInCorpore]

Originally Posted by Thorham

I can't, because I don't have an Atari ST Perhaps someone should just write a viewer

This is on my list for my online graphics converter tool.