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. as I said before: I want to see how far coders manage to push limits of hardware boundaries
OK - as English is not my native thus excuse my mistakes.
Raster interrupts are OK - its nice that Atari ST coders adapted idea from Atari 400/800 and Commodore 64 - this provide impressive result considering Jack Tramiel cost reduction concept and limited amount of time to design ST.
Amiga is slightly different (more comparable to Atari 400/800 but there is no ANTIC and there are some fundamental differences how video data are processed) and most of this type operations is performed by Copper (with all pros and cons). Raster interrupts can be used on Amiga without problems (necessary HW exist ad trig particular behavior on CPU side) but in multitasking environment it is better to use dedicated HW that provide HW synchronization with time critical event (as nature of the multitasking systems is purely asynchronous).
Anyway Raster interrupt is CPU (especially modern one) not friendly and simply this is dirty (8 bit time) hack.
Originally Posted by kovacm
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?
Yes - no one even doubt on this, this part of Amiga HW limitations are perfectly known however there is one thing you obviously missed - if Amiga start doing things in similar manner as ST we don't need to open 4 bitplane hires - we can use 2 bitplane hires and push data as ST. Very important thing - to avoid CHIP bus saturation we can relies on Fast RAM thus avoid (in most cases) mentioned problem. Overall we can do this like on ST but no one (except copper chunky) do this as it is done on ST side.
To conclude - you may assume that Lores 4 bitplanes/Hires 2 bitplanes are without speed limitation on CPU side (unless Copper/Blitter heavily used) - this is similar to ST. Also quite important difference is that Copper/CPU can manually feed BPLxDAT registers thus with lower number active bitplanes higher number color registers can be used (at least at some special cases and under some limitations) - this is not frequently used feature - in theory with clever pattern and temporal dither perhaps this can be used as substitute for tricky video mode - as HAM doesn't work in Hires (OCS/ECS) then we can't use HAM to improve this kind of functionality with software driven BPLxDAT (but we can in Lores) - not sure but as a technical concept probably you can do video fully pure software pumped (by CPU or Copper) just placing video data directly in BPLxDAT...