3D in demos - F030 vs Amiga 1200

[mc6809e]

Originally Posted by kovacm

^^
can I make one observation?

on ST, coders need, as you said "to emulate" (I would prefer phrase "to find way") to achieve Amiga capabilities. One of need was to display more than 16 colors onscreen so Atari coders find a way in 1987.: Spectrum 512 (http://www.asterius.com/atari/spectrum.html)

It is nice to see that Amiga coders adopt this idea.

Uh, Amiga coders didn't adopt this idea from Spectrum 512. Altering the palette mid-screen is an old idea. But without something like the COPPER, though, the technique can take a lot of CPU time. The COPPER was designed from the start to quickly alter hardware registers without wasting large amounts of CPU time.

Originally Posted by kovacm

as I said before: I want to see how far coders manage to push limits of hardware boundaries

btw "manually Copper can do more (but not more than 50 few changes per scanline)" - copper will do this with 0% CPU time, and some bus time, right? and one more thing: how much bus time will consume hires with 4 bitplanes on OCS/ECS?

The COPPER is synced to the display and runs it's own program independently of the CPU. A COPPER move instruction takes two even memory access slots (each memory access slot is two CPU cycles) to move 16 bits into a hardware register like a palette register. It may or may not cause the CPU to wait depending on other conditions. If the CPU is processing internally, the COPPER does not pause the CPU. If the CPU is accessing memory on an odd memory slot, the COPPER does not pause the CPU. But if the CPU tries to access memory on an even memory slot, and the COPPER needs to access memory at the same time, the COPPER causes the CPU to wait for the next available slot. That might be as little as two CPU cycles or it may be many cycles.

On the subject of four bitplane hires displays:

If my math is correct, with an interlaced screen and nothing else accessing chipram (refresh cycles only), one 312 line field has 69264 available memory access slots and a 313 line field has 69486 available memory access slots.

Running a 640x512 four bitplane display requires 40960 memory access slots leaving 28304 memory access slots on a 312 line field and 28526 memory access slots on a 313 line field.

The CPU isn't fast enough to use all these slots. At most it can use half of them so on average there are 14207.5 memory access slots available to the CPU per field. Normally a two bitplane hires display or a four bitplane lowres display allows the CPU to use between 34632 and 34743 slots so the additional bitplanes in hires reduce CPU performance by up to 60%.

The other half of the slots aren't necessarily wasted, though, and might be allocated to the COPPER, blitter, disk, audio, or sprites.

[kovacm]

Originally Posted by mc6809e

Uh, Amiga coders didn't adopt this idea from Spectrum 512. Altering the palette mid-screen is an old idea.

I will ask again: do you have any reference/proof ?

Originally Posted by mc6809e

It may or may not cause the CPU to wait depending on other conditions. If the CPU is processing internally, the COPPER does not pause the CPU. If the CPU is accessing memory on an odd memory slot, the COPPER does not pause the CPU. But if the CPU tries to access memory on an even memory slot, ...

it sound like Atari ST sync coding

joke aside, mc6809e yours technical comment are always very appreciated! beautifully and price explanation.

thanx again, much things are cleared now.

[mc6809e]

Originally Posted by kovacm

I will ask again: do you have any reference/proof ?

The Atari 2600 had just four color registers: Colump0, Colump1, Columpf, and Columbk. There is a single color for player sprite zero , a single color for player sprite one, a single color for the playfield (and ball), and a single color for the background.

That's a total of four colors.

Any Atari 2600 game then that shows more than four colors on screen at once is proof. Qbert released in 1983 for the 2600 creates a six color screen. There are two colors for the sprites, and four colors for the background pyramid. Breakout released in 1978 also for the 2600 is an earlier example of changing color registers to increase the total number of on screen colors.

It's no coincidence that one of the people responsible for helping design the 2600 went on to design the Amiga. Seeing the usefulness of changing color registers mid-screen, he invented the COPPER.

[pandy71]

Originally Posted by kovacm

I will ask again: do you have any reference/proof ?

There is many proofs or not - it depends how deeply you start searching but believe - idea to change something in synchronous way with display is old as computing.

Originally Posted by kovacm

it sound like Atari ST sync coding

don't blow balloon - it can explode...

[kovacm]

It's no coincidence that one of the people responsible for helping design the 2600 went on to design the Amiga. Seeing the usefulness of changing color registers mid-screen, he invented the COPPER.

and than, it is interesting that Amiga coders did not use this trick until... ???
(I just want to say that limitation of ST hardware, and far better competition machine: Amiga, push ST coders to do really amazing stuff! so "emulation of Amiga" is not a necessary a bad thing )

I bet that PCHG pictures looks better than HAM

[pandy71]

Originally Posted by kovacm

and than, it is interesting that Amiga coders did not use this trick until... ???
(I just want to say that limitation of ST hardware, and far better competition machine: Amiga, push ST coders to do really amazing stuff! so "emulation of Amiga" is not a necessary a bad thing )

Perhaps, but as i said previously - Amiga is multitasking, multiprocessor system, complex - check even this board - we still struggling with some aspects (HW and SW) - we don't have Suska and i afraid that near future will not bring to many solutions for community problems.
So as we can use 64 colors in one line (or 32 or HAM) color changing was seen more like curiosity - impressive but not very usable feature.

Originally Posted by kovacm

I bet that PCHG pictures looks better than HAM

And you can loose bet - HAM is very powerful and definitely underestimated - with good converter especially one wit some tricks and modern quantization algorithms it can provide optimal conditions to display almost any type of graphic.
There is lack of power on plain Amiga to use it frequently as HAM can be seen as compressed framebuffer thus processing is required to prepare data for framebuffer. HAM have also serious limitation - it is only LowRes.
But anyway Amiga have HAM, EHB and Copper and we can use this, together with correctly processed audio (especially for ECS or AGA) Amga can provide broadcast video quality with audio over 15 - 17 bit dynamics - i would say as for 20 year old technology not bad.
I really miss only one thing in AMiga - DSP similar to Falcon as standard from very beginning - even old TMS32010/32025 can be nice to have but... technology of 80's have own limitations.

[kovacm]

^
can you convert that three images to HAM?

[pandy71]

Originally Posted by kovacm

^
can you convert that three images to HAM?

I can do some experiment - prepare low res versions of those pictures with different types of color quantization.
For example plain PCHG (32 color LUT), PCHG EHB and PCHG HAM, also plain HAM. However as i wrote previously - as HAMLab is one of the best converters available for Amiga it still not produce best HAM possible, also it will not provide correct dithering for HAM but general dithering methods which are not optimal from HAM point of view.

[kovacm]

so you do not have tools to produce best possible HAM pictures? just made them best as you can.


and also, can you send original files?

I would like to try them on PhotoChrome on ST...

[mc6809e]

Originally Posted by kovacm

and than, it is interesting that Amiga coders did not use this trick until... ???

The first Amiga coders to use this "trick" were the programmers responsible for writing the operating system before the Amiga was even released.

Intuition, the windowing system of the Amiga, allows an application to open up its own screen with certain attributes, like resolution, number of colors, color palette, width, height, etc. But the Amiga is also a multitasking operating system, so there may be several programs running at the same time with different screen requirements.

Intuition uses the COPPER to allow several applications running simultaneously to share the same display by changing the color palette, the frame buffer address, even the resolution, mid-screen. The top half of the display might show a 320x100 32 color screen, for example, while the bottom half shows a 640x300 16 color screen.

It's an old trick made efficient by the COPPER and used in the Amiga from the start.

Originally Posted by kovacm

I bet that PCHG pictures looks better than HAM

Suppose that it does? There's very little CPU time left for anything else.

With HAM, 70% of the CPU time remains for things like decompressing a HAM animation. How many animated Photochrome images have you seen? And DMA is still available for audio, blitter, copper, sprites, and disk.

But if a programmer really wanted to he could page flip and use the COPPER to alter the 16 palette registers of a HAM image mid-scanline to improve it further. I think during HAM display the COPPER can perform 35 arbitrary writes to the 16 color palette available in HAM.

[kovacm]

Originally Posted by mc6809e

The first Amiga coders to use this "trick" were the programmers responsible for writing the operating system before the Amiga was even released.

like Atari programmers that wrote NEOchrome before Atari ST was released

I would not put Spectru512 in same basket as Intuition or NEOchrome...

otherwise, Amiga capability to display different resolution on same screen is really impressive!

Originally Posted by mc6809e

How many animated Photochrome images have you seen?

how many?? like 50 per second: [ Show youtube player ]

Originally Posted by mc6809e

And DMA is still available for audio, blitter, copper, sprites, and disk.

...with sound.

Originally Posted by mc6809e

But if a programmer really wanted to he could page flip and use the COPPER to alter the 16 palette registers of a HAM image mid-scanline to improve it further. I think during HAM display the COPPER can perform 35 arbitrary writes to the 16 color palette available in HAM.

[ Show youtube player ] is idea what you could try with Amigas...

[pandy71]

Originally Posted by kovacm

like Atari programmers that wrote NEOchrome before Atari ST was released

I would not put Spectru512 in same basket as Intuition or NEOchrome...

Intuition is name of OS subsystem in Amiga not application software - this is library used by system.
http://en.wikipedia.org/wiki/Intuition_%28Amiga%29

Originally Posted by kovacm

otherwise, Amiga capability to display different resolution on same screen is really impressive!

Yes, this is quite unique for Amiga thanks to Copper. Similar concept was Display List for ANTIC on Atari 8-bit.

Originally Posted by kovacm

how many?? like 50 per second: [ Show youtube player ]

Nope - trailer is 24 fps (cinema film framerate), also this is STE not ST and modification of hardware are required to transfer such high amount of data from external storage - CPU is turned to DMA channel - nothing else - show us 12 - 24 fps movie with mono sound decent quality on plain ST.

Originally Posted by kovacm

[ Show youtube player ] is idea what you could try with Amigas...

Perhaps some day - currently any Amiga (ie from 1985) can provide 25 fps animation for 368x568 with stereo sound 29073 samples per second - with smart using this to be honest i don't feel pressure to push limits with slow CPU further.

AGA is capable to do even better video - with reasonable fast CPU and smart use latest video standards - for example using YCoCg space instead YCbCr thus reduce time required to color space conversion, with using some of techniques used by H.264 (integer transformations) there is a chance for compressed FMV, audio sampling rate can be higher without trickes and thus dynamic range easily can excess 90 - 100dB provide more than 16 - 18 bit quality on ordinary Paula DMA audio channel.

[Mrs Beanbag]

Originally Posted by mc6809e

But if a programmer really wanted to he could page flip and use the COPPER to alter the 16 palette registers of a HAM image mid-scanline to improve it further. I think during HAM display the COPPER can perform 35 arbitrary writes to the 16 color palette available in HAM.

This is called Sliced HAM (SHAM). Newtek Demo Reel 1 (1987) showed this off in a hires interlaced imagine.

EDIT: The Netwek image wasn't actually HAM, now I come to look it up. You could do interlaced HAM but not HiRes. It did use palette changing trick though.

I wonder if originally the idea came from the old arcade machines that used a monochrome screen with a coloured filter on top.

[pandy71]

Originally Posted by Mrs Beanbag

This is called Sliced HAM (SHAM). Newtek Demo Reel 1 (1987) showed this off in a hires interlaced imagine.

EDIT: The Netwek image wasn't actually HAM, now I come to look it up. You could do interlaced HAM but not HiRes. It did use palette changing trick though.

Nope - NewTek AFAIR use CPU and their named this mode Dynamic Hires, SHAM is something else - AFAIR this is nicely explained in guide to PCHG library.

Originally Posted by Mrs Beanbag

I wonder if originally the idea came from the old arcade machines that used a monochrome screen with a coloured filter on top.

Original idea for what? dynamic changes for color?

[Mrs Beanbag]

Originally Posted by pandy71

Original idea for what? dynamic changes for color?

Yes. They added different coloured strips over the top of the black and white screen, thus changing the colour of objects depending on their position on the screen. Kind of like physical copper bars I guess. Obviously it wasn't dynamic but it provided a more interesting picture.

[pandy71]

Originally Posted by Mrs Beanbag

Yes. They added different coloured strips over the top of the black and white screen, thus changing the colour of objects depending on their position on the screen. Kind of like physical copper bars I guess. Obviously it wasn't dynamic but it provided a more interesting picture.

Ok, i see, yes for example http://en.wikipedia.org/wiki/Vectrex

[kovacm]

Originally Posted by pandy71

Intuition is name of OS subsystem in Amiga not application software - this is library used by system.
http://en.wikipedia.org/wiki/Intuition_%28Amiga%29

1. I know that
2. so what?

my point was that palette color changing was used in 1985. but not for displaying pictures.

Originally Posted by pandy71

Nope - trailer is 24 fps (cinema film framerate), also this is STE not ST and modification of hardware are required to transfer such high amount of data from external storage - CPU is turned to DMA channel - nothing else - show us 12 - 24 fps movie with mono sound decent quality on plain ST.

so what?

(yours replays are almost always offtopic! - mc6809e ask me: "How many animated Photochrome images have you seen?" and I replay that this video is exactly that - Photochrome images displayed at 50 frames per second!)

- it works on plain ST (of course without 50KHz DMA sound) and 512 color table
- modification if required only if you want to have same high speed for writings! (without modification you will get only 0.5MB/s write; read speed will be 3.5MB/s anyway)

Originally Posted by pandy71

... audio sampling rate can be higher without trickes and thus dynamic range easily can excess 90 - 100dB provide more than 16 - 18 bit quality on ordinary Paula DMA audio channel.

why would you process sound at 18bit precision when you have only 8bit DAC in Amigas ?!?

[Mrs Beanbag]

Originally Posted by kovacm

my point was that palette color changing was used in 1985. but not for displaying pictures.

Well a quick research reveals that Spectrum 512 was completed in 1987, the same year as the Newtek Demo Reel with its Dynamic Hires HAM. But Amiga doesn't actually have to rely on the CPU for this kind of palette changing trick, although that option is also open.

The Movie playback on Atari ST is truly impressive, my first thought was that the video must be a fake but I have looked it up and it seems real. I'll be honest I've never seen the like on the Amiga but then again it requires the video to be pre-calculated and streamed from a very fast hard disk because it couldn't decompress it fast enough. So it's a neat demo of what old hardware can do but not much practical use.

I do wonder, to be honest, if you only come here to say "Atari ST is better than Amiga, ner ner".

why would you process sound at 18bit precision when you have only 8bit DAC in Amigas ?!?

But Amiga has 4 of them, so combined you can get more than 8 bit. The easy trick is simply to play the least significant 6 bits on another channel at 1/64 volume, giving you 14 bit sound. I don't know how you would get 16 or 18 bit sound but maybe there are other ways.

[StingRay]

Originally Posted by Mrs Beanbag

I do wonder, to be honest, if you only come here to say "Atari ST is better than Amiga, ner ner".

He sounds like that in any of his posts in this very thread.

[pandy71]

Originally Posted by kovacm

1. I know that

it was not clear to me

Originally Posted by kovacm

2. so what?

my point was that palette color changing was used in 1985. but not for displaying pictures.

my (our) point is that Copper is used to do various things - not only to change content of color registers

Originally Posted by kovacm

so what?
(yours replays are almost always offtopic! - mc6809e ask me: "How many animated Photochrome images have you seen?" and I replay that this video is exactly that - Photochrome images displayed at 50 frames per second!)

Sorry for that but topic itself is not very strict or formal thus i see no problems to go sometimes off-topic but if you feel offended then please accept my apologies.

Originally Posted by kovacm

- it works on plain ST (of course without 50KHz DMA sound) and 512 color table
- modification if required only if you want to have same high speed for writings! (without modification you will get only 0.5MB/s write; read speed will be 3.5MB/s anyway)

Plain ST support mass storage with 3.5MB/s transfer ?

Originally Posted by kovacm

why would you process sound at 18bit precision when you have only 8bit DAC in Amigas ?!?

You are confused - i never said 18 bit precision and usually i process sound on 24 - 64 bit precision even if target is 8 bit. I said that should be no problems to achieve subjective 16 - 18 bit dynamics - this is something else. How it works? - similar as 1 bit converters in HighEnd audio.