Amiga Animation and CHIP RAM versus FAST RAM

[bloodline]

Zac67 wrote:
Well, TV displays are interlaced since TV signals{/i] are.  The Amiga's video signal may be non-interlaced, so that's what the monitor has to output.

My old Mitsubishi EUM even showed black lines between scan lines in non-interlace mode due to its low dot pitch.

Exactly! http://en.wikipedia.org/wiki/Technology_of_television#Display_technology
Anything synced with a TV will referesh at either 25 or 30 fps.

[platon42]

The Amiga (OCS/ECS or AGA) is capable of outputting animations at the display refresh rate, which is 60Hz for NTSC and 50Hz for PAL -- or other refresh rates (e.g. AGA modes like Super72 at about 72 Hz) -- and this is independent of the TV or display using interlace technique for half-frames. If the Amiga outputs the display in non-interlace mode, the same display lines will be updated, hence it is full 50/60Hz.

What is displayed during each frame depends on the copper list that selects the memory address for the displayed bitplanes. The Amiga is capable of multi-buffering which only requires a few pointers to be changed to switch between animation frames (with 2 MB chipram, about 25 full frames (320*256*8 bit (or HAM8)) can be stored in memory -- an A500 with 512KB chipmem can hold 8 full frames of HAM6 animation in memory). This means, you could play back 8 frames of uncompressed animation with nearly no CPU use (you could also have some of the bitplanes fixed to some graphics (like a colour gradient) and only update one bitplane, like I used this in the tunnel effect for my Tubes game graphics).

But usually an animation consists of more frames. Hence, only double buffering is used, hence while one frame is displayed, the next frame will be rendered using the CPU or blitter (e.g. for polygon gfx).

The anim5/7/8 etc formats use this technique for specifying the deltas between frame x and x-2, so depending on the amount of changes, not all 60KB for a 320*256*HAM6 frame need to be updated. Even a 68000 running at 7.14 MHz is capable of transferring memory that fast for 60 frames per second. As HAM6 is a hardware compression technique for 12 bit (4096 colours) into 6 bit, HAM6 has usually more delta due to digital noise in the image, for example in raytracing animations or movies. If the source of the anim is stored in fast ram, the cpu usually can operate a bit faster on it.

The iff-anim formats 5/7/8 are more or less the same and only differ in the width of the vertical slices that are used for updating the next frame. AFAIR anim5 uses byte (8 pixel wide) slices, whereas anim7 uses word (16 pixel) and anim8 uses longword (32 pixel) wide slices and thus are less cpu intensive -- at worse compression rate.

In summary: Comparing a 6 bit deep HAM6 animation in anim5 format might not be fair to compare against a 5 bit deep 32 colour animation in some other format using different compression. The Amiga itself is very well capable of real-time "one frame" animations.

Most games have "one frame" engines, such as Turrican, James Pond, Lionheart, Jim Power or Zool. Only a few use "2 frame" updates, such as Banshee or Magic Pockets.

Everything answered by now?

[Rowbeartoe]

bloodline wrote:

Zac67 wrote:

bloodline wrote:

It could be that Amiga software was almost always beam synchronised to ensure that the graphics wouldn't tear during redraws... I guess the Amiga was therefore at the mercy of the display device, if that was a TV, then it would be 25fps (PAL) or 30fps (NTSC).

Good point, but non-interlaced runs at 50 resp. 60 fps. However, the synchronized 'Amiga' way is what I was pointing at.

All TV displays are interlaced, regardless of what the Amiga is putting out. :-)

The Atari ST color monitor wasn't interlaced.  I'm sure the Amiga monitor wasn't interlaced as well.  Correct.

[bloodline]

Rowbeartoe wrote:

bloodline wrote:

Zac67 wrote:

bloodline wrote:

It could be that Amiga software was almost always beam synchronised to ensure that the graphics wouldn't tear during redraws... I guess the Amiga was therefore at the mercy of the display device, if that was a TV, then it would be 25fps (PAL) or 30fps (NTSC).

Good point, but non-interlaced runs at 50 resp. 60 fps. However, the synchronized 'Amiga' way is what I was pointing at.

All TV displays are interlaced, regardless of what the Amiga is putting out. :-)

The Atari ST color monitor wasn't interlaced.  I'm sure the Amiga monitor wasn't interlaced as well.  Correct.

Without knowing which model of monitor you are refering to, how are we to know? :-)

[meega]

Rowbeartoe wrote:
The Atari ST color monitor wasn't interlaced.  I'm sure the Amiga monitor wasn't interlaced as well.  Correct.

Wrong. It isn't the monitor that is interlaced...

PAL and NTSC both allow interlaced modes, and any monitor should be able to display them. It is a shortcoming of the Atari if it wasn't able to generate those signals.

[Rowbeartoe]

Zac67 wrote:

bloodline wrote:

It could be that Amiga software was almost always beam synchronised to ensure that the graphics wouldn't tear during redraws... I guess the Amiga was therefore at the mercy of the display device, if that was a TV, then it would be 25fps (PAL) or 30fps (NTSC).

Good point, but non-interlaced runs at 50 resp. 60 fps. However, the synchronized 'Amiga' way is what I was pointing at.[/quote]

All TV displays are interlaced, regardless of what the Amiga is putting out. :-)[/quote]

The Atari ST color monitor wasn't interlaced.  I'm sure the Amiga monitor wasn't interlaced as well.  Correct.[/quote]

Without knowing which model of monitor you are refering to, how are we to know? :-)[/quote]

Well I'm trying to focus on the 1985-1989 time frame.  So the Atari RGB montiors were the sc1224- made from goldstar and JVC i believe.  The Amiga monitors at the time?  not sure- I do know they were bigger than Atari's "large" 12inch displays.

[Rowbeartoe]

platon42 wrote:
The Amiga (OCS/ECS or AGA) is capable of outputting animations at the display refresh rate, which is 60Hz for NTSC and 50Hz for PAL -- or other refresh rates (e.g. AGA modes like Super72 at about 72 Hz) -- and this is independent of the TV or display using interlace technique for half-frames. If the Amiga outputs the display in non-interlace mode, the same display lines will be updated, hence it is full 50/60Hz.

What is displayed during each frame depends on the copper list that selects the memory address for the displayed bitplanes. The Amiga is capable of multi-buffering which only requires a few pointers to be changed to switch between animation frames (with 2 MB chipram, about 25 full frames (320*256*8 bit (or HAM8)) can be stored in memory -- an A500 with 512KB chipmem can hold 8 full frames of HAM6 animation in memory). This means, you could play back 8 frames of uncompressed animation with nearly no CPU use (you could also have some of the bitplanes fixed to some graphics (like a colour gradient) and only update one bitplane, like I used this in the tunnel effect for my Tubes game graphics).

But usually an animation consists of more frames. Hence, only double buffering is used, hence while one frame is displayed, the next frame will be rendered using the CPU or blitter (e.g. for polygon gfx).

The anim5/7/8 etc formats use this technique for specifying the deltas between frame x and x-2, so depending on the amount of changes, not all 60KB for a 320*256*HAM6 frame need to be updated. Even a 68000 running at 7.14 MHz is capable of transferring memory that fast for 60 frames per second. As HAM6 is a hardware compression technique for 12 bit (4096 colours) into 6 bit, HAM6 has usually more delta due to digital noise in the image, for example in raytracing animations or movies. If the source of the anim is stored in fast ram, the cpu usually can operate a bit faster on it.

The iff-anim formats 5/7/8 are more or less the same and only differ in the width of the vertical slices that are used for updating the next frame. AFAIR anim5 uses byte (8 pixel wide) slices, whereas anim7 uses word (16 pixel) and anim8 uses longword (32 pixel) wide slices and thus are less cpu intensive -- at worse compression rate.

In summary: Comparing a 6 bit deep HAM6 animation in anim5 format might not be fair to compare against a 5 bit deep 32 colour animation in some other format using different compression. The Amiga itself is very well capable of real-time "one frame" animations.

Most games have "one frame" engines, such as Turrican, James Pond, Lionheart, Jim Power or Zool. Only a few use "2 frame" updates, such as Banshee or Magic Pockets.

Everything answered by now?

Part of what I orginally asked was-

"when I had side by side comparisons I noticed that the Amiga 500 never could do 60fps animations? We even had Antic software with Cad 3D 2.0 on both computers, but the Amiga was limited to 30fps at best. I remember having several (albeit slightly downgraded graphicly) Amiga HAM-6 animations such as the juggler, or a Scult 3D demo converted to Spectrum 512 running at 60fps on the ST. I could never answer the question to customers if the Amiga animation software could match that speed.

Cyperpaint on the ST was Zoetrope on the Amiga- was the Amiga version capable of 60fps? My question is does any Amiga software for the 500,1000, or 2000 allow full screen 320x200 animations at 60fps? Turbo Silver 3.0, VideoScape 3d, Photon Video Cel Animator, Deluxe Paint III, and Photon Paint II all had animation capabilities on the Amiga. But none of my magazines mentioned how fast these animations could go. The reviewers always neglected to mention if it could. That along with my personal experience suggests the Amiga could not. Am I wrong?

If not, was it the CHIP RAM in the Amiga preventing 60fps animations? Was it the slightly slower clock speed (7.1 MHz vs 8.0 MHz) of the 68000? Was it the more memory intense files of the Amiga- Atari's 4bit versus Amiga's 5bit picture files? Was it perhaps the Amiga 500 only had 512K?

Thanks for you help everyone. "

I'm still at a loss if the Amiga software allowed it's users from 1985-1989 for the orginal Amigas (500,1000,2000) could page flip 60fps animations like I could with my Atari ST (albeit a differn't graphic quality)

Thanks everyone for you time and thoughts.

[platon42]

If not, was it the CHIP RAM in the Amiga preventing 60fps animations? Was it the slightly slower clock speed (7.1 MHz vs 8.0 MHz) of the 68000? Was it the more memory intense files of the Amiga- Atari's 4bit versus Amiga's 5bit picture files? Was it perhaps the Amiga 500 only had 512K?

Sigh.

Using 5 or 6 bitplane modes in OCS/ECS (A500) in lowres will hurt CPU performance when accessing CHIP ram, as even and some odd cycles (normally reserved for the CPU) are used for display DMA. I think it was about 17% slower for 6 bitplanes (six bitplanes for HAM6, not five as you said). I don't know how the ST accessed its memory and if it had to share CPU cycles with the display controller. Probably it had, but I don't know the impact.

And yes, 7.1Mhz vs 8 MHz also has an impact.

And yes, 6 bitplanes is more memory intense than 4 (16 colours) or 5 (32 colours) bitplanes, thus more cpu power is required to process it.

And no, it is not about the less memory.

And I still claim that it was possible to achieve 60fps on a standard A500 with HAM6 animations at 320x200 pixels and only 512KB chipmem (there were some scene demos doing exactly that). But I am not sure that the anim5 was suitable for that due to compression scheme -- hence I cannot confirm that the software players would achieve 60 hz on that particular animation you were mentioning.

[JetRacer]

@ varius people: I didn't try to claim some Amiga superiority nut opinion nor anything. -Ofcourse there exist dedicated video editing stuff that does this flawlessly for every platform. I meant some basic form of diplay tool most people use. Such always performs/behaves equally poorly under previusly mentioned circumstances no matter which platform one turns to. That's all.

[Sig999]

JetRacer wrote:
@ varius people: I didn't try to claim some Amiga superiority nut opinion nor anything. -Ofcourse there exist dedicated video editing stuff that does this flawlessly for every platform.

I mentioned clients who don't have any bells and whistles to VIEW this.

As for dedicated video editing stuff - this aint the era of Video Toaster anymore - 10 million cards and a hole in your wallet. You can comfortably edit video with little more than a PC and a copy of Adobe Premier - Mac and final cut... even less - I think xp has a crappy home video slap together program , and I know the Mac has one too.

My home edit system does have the Avid SDI, but then again I edit professionally - my 'muckaround' system doesn't.


Maybe put the old noggin into research mode before announcing these 'facts'  :-?

The topic was about a comparison of the Atari ST to the Amiga on an animation program - I don't see what point dragging the PC and what it might and might not be able to do compared to an Amiga has to do do with that anyways...

[stefcep2]

The topic was about a comparison of the Atari ST to the Amiga on an animation program - I don't see what point dragging the PC and what it might and might not be able to do compared to an Amiga has to do do with that anyways...

Thats because you are on an amiga site where too many people can't forget that the amiga was ONCE the king (or is it queen) of video.

Going on-topic: the guy wants to know : could a stock A500 do animations at 50/60 frames/sec because he only saw 25/30 frames/sec or was this due to software not letting you create anims that playback at 50/60 frames/sec:

1. The hardware could playback 300x200 at 60 fps.

2. 60 fps is not really 60 full frames every second: its really one frame that has every even scan line displayed, followed by the same frame where every odd scan line is shown ie interlaced, and this flickers.  Was the Atari running an interlaced mode?  If not are you absolutely sure that it was running at 60 fps?  Did the animation look smoother but flicker on the Atari?  

2.  Its likely that 30 frames per second was chosen because the animations on the amiga were ham6, and this was by far the slowest format.  Further AFAIK anim5 was EA's animation format, used by dpaint at the time and I have just run dpaint 2 and 3 and i cannot see a way to change the fps, it seems to be hardcoded to do animations at 30 fps.

3.  Its likely that the whilst the A500 could have done 60 fps at 300x200, the animations that you viewed were made to run at 30 fps because a) they were in Ham6 format and b) this was a software limitation of the anim5 format.

[Sig999]

stefcep2 wrote:
Thats because you are on an amiga site where too many people can't forget that the amiga was ONCE the king (or is it queen) of video..

I concur - once was. It's the folks who think 'still is' that make me wonder

[amigaksi]

>...when I had side by side comparisons I noticed that the Amiga 500 never could do 60fps animations? We even had Antic software with Cad 3D 2.0 on both computers, but the Amiga was limited to 30fps at best. I remember having several (albeit slightly downgraded graphicly) Amiga HAM-6 animations such as the juggler, or a Scult 3D demo converted to Spectrum 512 running at 60fps on the ST....

You need to give some better way of proving that the ST version actually ran at 60fps in 320*200*16 since the naked eye has its limitations of noticing frame rates above 25fps.  I'll give you an example how to quantify your results.  Without using the blitter chip and with the sound and copper running in the background, I was able to paint 320*200 full frames at the following rate on an A500 running at 7.16Mhz: at 3 planes (8 colors/pixel) 52 fps, at 4 planes (16 colors/pixel) 39 fps and in HAM mode 19 fps.  The following is the code used to test and it compiles and uploads to the real Amiga with MPDOS Pro (www.mpdos.com):


      ORG $10000

      Bra.s   ProgStart

CopperList:   
      DW $E0,$0000,$E2,$4000   ;Bplane#0 at $4000
      DW $E4,$0000,$E6,$4028   ;Bplane#1 at $4000 + 40
      DW $E8,$0000,$EA,$4050   ;Bplane #2 at $4000 + 80
      DW $EC,$0000,$EE,$4078   ;Bplane #3 at $4000 + 120
      DW $F0,$0000,$F2,$40A0   ;Bplane #4 at $4000 + 160
      DW $F4,$0000,$F6,$40C8   ;Bplane #5 at $4000 + 200
      DW $180,$F00      ;red color
                 DW $2c81,$fffeh         ;WAIT for video beam (X,Y) = (112,44)
      DW $180,$0      ;black color
      DW $5E01,$FF00h   ;wait for (x,y) = (0,94)
      DW $180,$0F0      ;green color
      DW $9001,$FF00h   ;wait for (x,y) = (0,144)
      DW $180,$00F      ;blue color
      DW $C201,$FF00h   ;wait for (x,y) = (0,194)
      DW $180,$FF0      ;yellow
      DW $F401,$FF00h   ;wait for (x,y) = (0,244)
      DW $180,$0FF   ;cyan
      DW $FF01,$FF00h   ;wait for (x,y) = (0,255)
      DW $180,$F0F      ;magenta
      DW $FFFF,$FFFE
ProgStart:
      Move.l   #CopperList,$DFF080   ;1st copper list.  
      Move       #2,$dff088         
      Move       #$2c81,$dff08e        
      Move       #$F4C1,$dff090       
      Move.l   #$3800D0,$dff092    
      ;Move   #$d0,$dff094          
      Move       #$4204,$dff100     ;use $6A04 for HAM mode
      Move       #0,$dff102             
      Move   #$24,$dff104           
      Move   #0,$DFF106   ;unused in OCS
      Move       #$C8,$dff108        
      Move   #$C8,$dff10a             
      Move   #$C080,$DFF09a   
      Move       #$8381,$dff096   
      Move   #16-1,D1
      Move.l   #$DFF180,A0 ;color register #0
      Clr.w   D0
SetPalette:   Move   D0,(a0)+
      Add.w   #$111,D0   ;next shade
      Dbra   D1,SetPalette

      Move.l   #1200,D3
      ;Move.l   #$0000FFFF,D3
      
NextFrame:   Lea   $4000,A0  ;plane #0 at $4000
      Move   #200-1,D1
NextLine:      Moveq   #5-1,D0   
SetPixels:      ;Move.l   #-1,$C8(a0)   ;plane #5
      ;Move.l   #$0,$A0(a0)   ;plane #4
      Move.l   D3,$78(a0)   ;plane #3
      Move.l   #$00FF00FF,$50(a0)   ;plane #2
      Move.l   #$0F0F0F0F,$28(a0)   ;plane #1
      Move.l   #$33333333,(a0)+   ;plane #0
      ;Move.l   #-1,$C8(a0)   ;plane #5
      ;Move.l   #$0,$A0(a0)   ;plane #4
      Move.l   D3,$78(a0)   ;plane #3
      Move.l   #$00FF00FF,$50(a0)   ;plane #2
      Move.l   #$0F0F0F0F,$28(a0)   ;plane #1
      Move.l   #$33333333,(a0)+   ;plane #0
      Dbra   D0,SetPixels
      Adda   #200,A0
      Dbra   D1,NextLine
      Dbra   D3,NextFrame
      
AllDone:      Move.w   $DFF006,D1
      Lsr.w   #4,D1
      Move   D1,$DFF180
      Jmp   AllDone

      DW   2 dup(0)

[Rowbeartoe]

You need to give some better way of proving that the ST version actually ran at 60fps in 320*200*16 since the naked eye has its limitations of noticing frame rates above 25fps.  I'll give you an example how to quantify your results.  Without using the blitter chip and with the sound and copper running in the background, I was able to paint 320*200 full frames at the following rate on an A500 running at 7.16Mhz: at 3 planes (8 colors/pixel) 52 fps, at 4 planes (16 colors/pixel) 39 fps and in HAM mode 19 fps.  The following is the code used to test and it compiles and uploads to the real Amiga with MPDOS Pro (www.mpdos.com):


Thanks again EVERYONE for trying to settle this long time question of mine.

Proof- sigh.

Well, this wasn't rocket science.  For one, the software on the ST said it was 60fps, and for proof all I would have to do is load 30 frames and play it as 60fps and I'd see all of them displayed twice every second- id notice if it went only once.  The HAM-6 juggler demo runs at 24 or 30fps if I recall, and once that was converted to the ST, it was at least twice as fast- but again that was because I tested the speed of the ST and the software package claimed it to be.  While I'd be hard press to tell the differnce between 55 or 65fps, I'm sure  it was, since F10 for full speed with the viewer software, and f9 was half, and the space bar was frame by frame.  Each function keyed allowed a differn't speed, come to think of it, I think the software told me what each funntion key did.  with that knowledge, and placing the two computers side-by-side with 3 of the same animation demos, I was shocked to notice the ST was page flipping at least twice as fast- ableit once again with graphic pictures that took up less memory- (well Spectrum 512 pictures uncompressed took up 50kilobytes- versus uncompressed 16 color 32 kilobyte files on the ST).  

I hope that is proof enough- as for the interlaced issue, I spent days drawing pictures with my eyeball pressed up against my Atari 12" RGB monitor- it was not flickering.  

Thank you everyone for your help.  =)

[Georg]

Most games have "one frame" engines, such as Turrican, James Pond, Lionheart, Jim Power or Zool. Only a few use "2 frame" updates, such as Banshee or Magic Pockets.

I'm not sure and I may remember wrong but some games might even have been "3 frame" ones. I think Magic Pockets was one that felt like running on a very slow FPS rate. The funny thing is that IMO sometimes a slower framerate may look/work better than a faster framerate, if the faster of the two is in a certain range. For example 25Hz framerate may look/work worse than 16Hz because of the way the jerky/non-smooth video update "feels" when seen. Doom was limited to 35 FPS which is a very evil framerate where some people can get motion sickness.

Some amiga games were also cheating somewhat in that they had only the scrolling (and usually the main player sprite) running at full frame rate while the real game or the rest of the game was only running at half the rate. Like several Team17 games.

Another game I remember is Midnight Resistance which to me looked like running in full frame rate although it didn't, because of the way the gfx/colors were chosen/painted.

[amigaksi]

>Well, this wasn't rocket science. For one, the software on the ST said it was 60fps, and for proof all I would have to do is load 30 frames and play it as 60fps and I'd see all of them displayed twice every second- id notice if it went only once...

It may skip frames while attempting to play at 60fps.  Given the fact that ST is 8Mhz and Amiga 500/1000 are at 7.16Mhz simple processor-based memory transfers would be slightly faster on ST but not 30fps vs 60fps and this is also assuming the RAM chips are not the bottleneck.  The code I gave before was running from Chip RAM and copying to Chip RAM the slowest RAM in the Amiga.

>...funntion key did. with that knowledge, and placing the two computers side-by-side with 3 of the same animation demos, I was shocked to notice the ST was page flipping at least twice as fast- ableit once again with graphic pictures that took up less memory- (well Spectrum 512 pictures uncompressed took up 50kilobytes- versus uncompressed 16 color 32 kilobyte files on the ST).

There could be a software limitation on the application used.  What's the format of the 50Kb of Spectrum 512-- is that also 320*200*16 with palette changes every scan line?  50Kb per frame at 60fps would be 3Megabytes/second.

>I hope that is proof enough- as for the interlaced issue, I spent days drawing pictures with my eyeball pressed up against my Atari 12" RGB monitor- it was not flickering.

I wasn't asking about interlaced stuff since you can always enable/disable interlace with one bit in register mentioned before (one that was poked with 4204h) without affecting performance.