Amiga Animation and CHIP RAM versus FAST RAM

[Zac67]

I'd venture the replay routines on the Amiga were optimized/designed to allow replay of interlaced frames. There are only 30 interlaced fps, so the coders didn't include a special faster non-interlace mode replay of up to 60 fps.
The Ataris lack interlace mode, so you'd code for 60 fps from the start.

Maybe as simple as that.

[Zac67]

Please show me a non-crappy integrated video chipset... :roll:

The Whitney chipset had many problems and is best rapidly discarded.

[Zac67]

The notebook I'm typing this on has an i945GM chipset and I kept experiencing system crashes w/ DirectX in tighter memory situations. Only after expanding to 2 GB this has somewhat grown better.
I had a GIF image that kept bluescreening the system when the Explorer's preview function was used - on all Intel graphics systems I tried it on. I haven't found one single nVidia or ATI driven system to crash with it - I've tested ~25 machines.
Go figure.

[Zac67]

The - supposed - limitation would not be due to the file format, but the replay routine. On the Amiga Copper lists are used for most video timings. This suggests to trigger the page flip on the very last video line (only present on the 2nd field), thus limiting the replay speed to 30 fps (for NTSC). There might even be some OS support for this method (can't find my KRM right now).

Hasn't anyone here actually low-level coded something like this?

[Zac67]

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.

[Zac67]

Well, TV displays are interlaced since TV signals 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.

[Zac67]

Actually, there's no sense in running any anim with >30 fps - your eyes wouldn't see the difference anyway (60 fps vs 30 fps with every other frame skipped). That's the exact reason why cinema/PAL/NTSC work with 24/25/30 fps: their designers wouldn't waste film/bandwidth.

The Amiga programmers were obviously aware of this and just coded that way.

[Zac67]

With the frames in raw format, you could end up with 0% CPU load: let the copper handle all the page flipping (rather lengthy list, but with only a few frames to play).

But: if you have no fast RAM and use HAM (6 planes) you end up with 50% less bandwidth during bitplane DMA. Depending on overscan width, you'd get 25-45% speed penalty for the CPU.

In addition (with fast RAM), you would probably store the ANIM data in fast and decompress directly from fast to chip, so you could use the remaining 55-75% of chipram speed to fill the frames; with few enough bytes to change you could just about get away with full 60 fps.

The Atari STs could only do 16 colors, and with only 4 bitplanes you'd have no speed penalty on the Amiga, so 60 fps would be a piece of cake (with or without fast RAM).

[Zac67]

To repeat my theory: The programmers coded that way to allow non-interlaced as well as interlaced anims - you usually program as universally as reasonable. They regarded 30 fps as sufficient (which it usually is, at least if the frames are made for it (video captured / motion blurred).

The Atari programmers didn't have to watch for non-/interlace differences since the STs can't output the former (only with tricks).

[Zac67]

A standard ST can be considered 'chip RAM only' since framebuffer data can be put everywhere.
The ST uses a static bus priority scheme where half of the cycles are used by graphics/sound/whatever DMA and the other half is used by the CPU. A plain 68000 can't use any more cycles anyway. This explains why the ST can only do 16 colors in 15kHz and two in 31(?) kHz.

This is in contrast to the Amiga's dynamic bus scheme where up to half of the CPU's cycles can be reissued to chipset DMA (with the blitter nasty bit all of its cycles) - actually it's rather like the CPU is DMAing into the memory belonging to the chipset (i.e. connected to Agnus).

[Zac67]

NTSC and PAL are very well capable of displaying full 60/50 fps NON-INTERLACED. In interlace mode the frame rate drops to half, but vertical resolution doubles (same horizontal scan rate of course).

[Zac67]

Never heard of Spectrum 512 before, but as I understand it, it's a software hack to change the ST's palette beam synced on each scanline. Of course this puts a load on the CPU, allows for >16 colors on the screen but OTOH doesn't allow >16 colors per scanline.

The same method can be used on the Amiga, only that - of course - you'd use the Copper instead to do the palette rewrite stuff, completely supported by the OS.

Also you could use 5 bit planes to display 32 colors, use EHB or even HAM which could definitely display better colors. In other words: you could convert a Spectrum 512 pic to the Amiga (16 color lores plus dynamic palette). Actually SHAM uses the same method, so it MUST look better - provided the same care is taken when converting the pic. All examples I could find on the 'net seem to support this statement...