Missing Display modes

[bloodline]

Originally Posted by NorthWay

I never got why the Copper is every other access slot. Logic timing limits?

In a single scanline you have enough time for 227 16bit memory accesses (read or write). So all the odd accesses are given to time critical operations, the even slots are then given to the copper, then the Blitter then the CPU. The general exception to this is when the bitplane DMA is active (for around 160 word slots) where the display is fetched from ram.

See below:

http://amigadev.elowar.com/read/ADCD.../node02D4.html

[Gorf]

Originally Posted by NorthWay

I never got why the Copper is every other access slot. Logic timing limits?

As Bloodline explained ... it needs to read the next instruction from RAM.
So a way around that would be sort of cache or internal copper RAM to store a copper-list ... but that would limit the size of the list.

And the Blitter could have had a mode where it used hw sprite data as input. Or is that actually possible for 2bpl mode with the right minterm?

Not exactly sure what you mean by that. Sprites are just locations in RAM that are read every scan line before other display data. So you can apply Blitter operations on them.
edit:
I think I know now what you mean...
you can not simply mix sprite-data with other bitplane-data, because sprites are arranged in interleaved mode... so you can use the Blitter to move the memory region around, but not much more ... well you can use other operations als well, but the result is probably not what you want.

(Do you want more from my list of "missed opportunities in OCS"? :-)

bring it on!

[NorthWay]

Originally Posted by bloodline

In a single scanline...

Why did I even ask that, I actually knew it if I just thought about it. I think I have confused myself by misunderstanding something from the Minimig Verilog code. Bah!

Missed opportunities in OCS:
- Copper burst(multimove) mode. There are enough "xxx" bits in the upper part of register addresses to use that for a count variable. For example, start at register $0180 and keep increasing while writing the next 32 words. If the Copper is a state machine then it should be possible to do an add and skip to the second part of the "register,value" fetch logic. Unless an adder was too expensive?
- An extra Copperlist or Copper-interrupts as AAA names it - also called a Blipper. Nearly exactly the same as a Copper except it only writes Blitter registers and waits for Blitter finished. Plus some kind of a/sync signaling and starting and stopping.
- A "virtual" Copper. Seeing how the OS supports multiple screens you can drag down, I believe it jumps through hoops to make it happen - updating copperlists here and there. If you had something like COP3LC that could be called as a subroutine that returned after postition XY you could have a virtualised raster line number where every screen starts at line 0 with the display window shortly after at line 2(?). I.e. all screens never change their copperlist, but the master list starts each one at the correct position and lies to it about what line we are at now.
- DDFWRAP and BPL1WRP+BPL2WRP . Like DDFSTOP and BPL1MOD but it does display wraparound without gaps midscreen. Think for a Defender like game, or for splitting right and left side as independent.
- An option for hw sprites where, at the end of the sprite as it is today, there is a further 32 bits that is a pointer to another sprite structure in memory. HW sprites aren't really designed for animating individual segments when you use their start/stop feature to multiplex them. You can use the Copper to do this for you AFAIK, but that is inelegant. This would add an extra gap line before re-use because of the extra two word fetches.

[NorthWay]

Originally Posted by Gorf

you can not simply mix sprite-data with other bitplane-data, because sprites are arranged

Without much thought: (3-colour sprites only)
BLTAMOD = 2 ; sprite data first word
BLTBMOD = 2 ; sprite data second word
BLTCMOD = screenwidth-2
BLTDMOD = screenwidth-2
((!(A OR B)) AND C) OR A)
((!(A OR B)) AND C) OR B)
(!(A OR B)) AND C)
Non-interleaved blits. First minterm used on 1+ bitplane. Second minterm used on 1+ other bitplane. Last minterm used on the remaining bitplanes. All depending on which palette entry you want it to end up as.
(Mask is both words ORed and inverted. Cut bits away from source. Optionally fill in data. Store to destination.)

[Megol]

Originally Posted by bloodline

ECS had the bandwidth... but not the palette capacity.

It still worked fine for the Acorn Archimedes that had a 16 entry palette. 4 bits of a pixel was used as the palette index and 4 bits modified the RGB value read. Amiga could do it better with its 32 entry palette. The 3 remaining bits could be used to:

• Change the MSb of each R,G,B value
• Change the LSb of each R, G, B value.
• Have a per R, G, B half-brite function.

[bloodline]

Originally Posted by Megol

It still worked fine for the Acorn Archimedes that had a 16 entry palette. 4 bits of a pixel was used as the palette index and 4 bits modified the RGB value read. Amiga could do it better with its 32 entry palette. The 3 remaining bits could be used to:

• Change the MSb of each R,G,B value
• Change the LSb of each R, G, B value.
• Have a per R, G, B half-brite function.

You’re right since a byte per pixel chunky mode on OCS would have had three spare bits, it could have included some really exotic pixel modes. My favourite idea is to have a “low colour” RGB mode: 2 bits Red, 3 bits Green, 2 bits blue... or something similar.

[Gorf]

@ Megol, bloodline

but the bandwidth on OCS/ECS would be maxed out with a 8bit chunky mode in low-res - as it would with 8 bitplanes ...
So during the screen-time everything else would be blocked.

And the same could be done by simply using additional bitplanes for e.g. rgb-color-specific EHB mode ...

my point: while an interesting idea, such a chunky mode does not really have benefits over bitplanes in the old 16-bit design, since the CPU and Blitter are blocked most of the time and the Blitter can't even handle this format.

(later non 32bit (AGA) one would want a real chunky 8-bit 256 color mode and 16bit truecolor ...)

[Gorf]

Originally Posted by NorthWay

- Copper burst(multimove) mode. There are enough "xxx" bits in the upper part of register addresses to use that for a count variable. For example, start at register $0180 and keep increasing while writing the next 32 words. If the Copper is a state machine then it should be possible to do an add and skip to the second part of the "register,value" fetch logic. Unless an adder was too expensive?

good idea!
I do not think it would be to expensive ... only problem might be some kind of instability or the possibility to stall the copper forever? not sure..

- An extra Copperlist or Copper-interrupts as AAA names it - also called a Blipper. Nearly exactly the same as a Copper except it only writes Blitter registers and waits for Blitter finished. Plus some kind of a/sync signaling and starting and stopping.

or at least simple fifo-pipeline to fill in multiple Blitter instructions...

- A "virtual" Copper. Seeing how the OS supports multiple screens you can drag down, I believe it jumps through hoops to make it happen - updating copperlists here and there. If you had something like COP3LC that could be called as a subroutine that returned after postition XY you could have a virtualised raster line number where every screen starts at line 0 with the display window shortly after at line 2(?). I.e. all screens never change their copperlist, but the master list starts each one at the correct position and lies to it about what line we are at now.

also a good idea.

- DDFWRAP and BPL1WRP+BPL2WRP . Like DDFSTOP and BPL1MOD but it does display wraparound without gaps midscreen. Think for a Defender like game, or for splitting right and left side as independent.

Here we go!

that's something I was thinking about too. And I would call it "stitcher mode".
I would try to make this more flexible, so that a couple of rectangular regions could be "stitched" together that way.
This would allow e.g. for a window in wb to be moved around in opaque mode, without any blits.

I think I have some Ideas how this could work, without too much changes in hardware ... but I guess I have to write/draw that down on pen and paper first, to see If this really works

[NorthWay]

Originally Posted by Gorf

I would try to make this more flexible

The thing is, I think DDFWRAP would be next to no cost if the hw logic is implemented as I'm guessing: Bitmap pointers are always fed through an adder after each fetch. If the fetch has reached DDFSTOP then it selects BPLxMOD as input for the adder, if not then it selects "2". You would only need one more compare and select when adding DDFWRAP logic.

[Megol]

Originally Posted by Gorf

@ Megol, bloodline

but the bandwidth on OCS/ECS would be maxed out with a 8bit chunky mode in low-res - as it would with 8 bitplanes ...
So during the screen-time everything else would be blocked.

Chunky would simply have half the horizontal resolution of a 4BPL planar mode, 320x256 4bpl -> 160x256 8bpp. Good enough for Wolfenstein or DOOM.

And the same could be done by simply using additional bitplanes for e.g. rgb-color-specific EHB mode ...

Of course but this was about making 8bpp chunky more useful without needing to add more palette entries. Some small changes that should have been possible at the ECS release.

my point: while an interesting idea, such a chunky mode does not really have benefits over bitplanes in the old 16-bit design, since the CPU and Blitter are blocked most of the time and the Blitter can't even handle this format.

It could still be used unchanged for word aligned block moves, right?

(later non 32bit (AGA) one would want a real chunky 8-bit 256 color mode and 16bit truecolor ...)

Yes but then I'd assume one could make some larger changes and increase the fetch bandwidth.

Cost of adding highcolor if 8bpp chunky is already there: a 16 wide selector for RGB data, a few gates in the sequencer (to inhibit byte shift). The video DAC would have to be changed too of course but the palette RAM could still be untouched.

320x256 4bpl -> 80x256 16bpp.
640x256 4bpl -> 160x256 16bpp.

[Gorf]

Originally Posted by Megol

Chunky would simply have half the horizontal resolution of a 4BPL planar mode, 320x256 4bpl -> 160x256 8bpp. Good enough for Wolfenstein or DOOM.

good enough is relative, but that is a valid point.
I somehow did not think of reducing the resolution below low-res....

Of course but this was about making 8bpp chunky more useful without needing to add more palette entries. Some small changes that should have been possible at the ECS release.

right.

It could still be used unchanged for word aligned block moves, right?

yes.

[Gorf]

Originally Posted by NorthWay

The thing is, I think DDFWRAP would be next to no cost if the hw logic is implemented as I'm guessing: Bitmap pointers are always fed through an adder after each fetch. If the fetch has reached DDFSTOP then it selects BPLxMOD as input for the adder, if not then it selects "2". You would only need one more compare and select when adding DDFWRAP logic.

Yes but that would only give you one split from top to bottom (unless you change things with the copper...)

It would be nicer if DDFWRAP could also take a start line and end line - there should be enough bits left in the register.

And more than just one DDFWRAP register would be also nice - well just a ring-buffer is really needed, to replace the first position with the next once the position is reached - so still just 2 compares.

that is all nice, but we do have a small problem: it works only at 16pix borders.
And only really for vertical scrolling - horizontal scrolling of the left side would lead make the split-line jump back and forth - or introduce a black stripe between 0 and 16 pixels wide...

So there comes the next Idea: we would need to prefetch the missing date (up to 16 pixels) before the line start ... --> misusing sprites.


Actually I would introduce a second sprite format, that is now finally organized in bitplanes, as the rest of the screen data ... so basically a 16bit wide stripe of a normal screen. Additionally the sprite contains now the DDFWRAP position and start and stop line (like any sprite) - problem solved without heavy copper use.

[pandy71]

Originally Posted by Hewitson

Interlace doesn't count. Also, it's only capable of 16 colours.

ECS/AGA can be progressive (at a cost of framerate) In theory you can have 2047 lines of video thus with 15kHz H Sync you will have video like 7.63fps

Pixel clock (constant for Amiga custom chips and derived from 28, 14, 7MHz) is your first limit, second limit is Horizontal sync frequency or line length (normally 15/31kHz but i think it can be controlled by proper programming also on OCS) and finally your line number or frame rate.

IMHO:

Chip RAM speed can be easily increased by faster clock and using advanced fetch modes thus redesigning overall state machine can be best method to improve Amiga capabilities (new features can use new cycles and to provide compatibility keep old cycles for OCS).
Unifying memory (feasible in SDRAM) so no longer issue with moving data between FAST and CHIP memory (64 bit DDR with 2048 * LWORD Burst).

Most important feature that Amiga miss is CLUT with Copper fast switch ability (for example 32768 color registers with lower address accessible as basic color registers but upper address bits controlled by Copper). AGA has some limited functionality on this but rather crippled (BANKx in BPLCON3)
Some neat trick from VGA RAMDAC can be also implemented - auto-increment to quickly write values to CLUT.
Also mask feature (on bitplanes) could be nice (similar to EGA/VGA).

Copper could have own local (rather small like 32kW) RAM (accessible by CPU directly or indirectly) thus able to perform own program without competing with Blitter and CPU.

Some modifier to pixel/RGB data (similar to E-HAM, DCTV etc).

As EDSUN patent expired then CEG DAC can be implemented (HW anti-aliasing).
http://archive.gamedev.net/archive/r...rticle371.html
http://archive.gamedev.net/archive/r...rticle370.html
https://www.analog.com/en/analog-dia...ances-vga.html
https://patents.google.com/patent/US4482893A/en
https://patents.google.com/patent/US4704605A/en

Originally Posted by Gorf

Actually I would introduce a second sprite format, that is now finally organized in bitplanes, as the rest of the screen data ... so basically a 16bit wide stripe of a normal screen. Additionally the sprite contains now the DDFWRAP position and start and stop line (like any sprite) - problem solved without heavy copper use.

You can add local RAM accessible by CPU directly or indirectly to store SPRITE data (thus no longer demand main RAM cycles - like 64kW - such small RAM is typical for FPGA - name it as SPRITE CACHE)

[Gorf]

Originally Posted by pandy71

Most important feature that Amiga miss is CLUT with Copper fast switch ability (for example 32768 color registers with lower address accessible as basic color registers but upper address bits controlled by Copper).

not sure if I understand you here correctly....
I guess you do not mean 32 thousand registers, do you? But 15bit wide registers that allow 32k different values?

Would limiting the copper to higher bits make things really faster? How?

AGA has some limited functionality on this but rather crippled (BANKx in BPLCON3)

due to the 8bit wide RGA bus the Amiga can only address 256 registers in total .... this should habe been changed for AGA by adding one or two extra lines ...

Some neat trick from VGA RAMDAC can be also implemented - auto-increment to quickly write values to CLUT.

True.
Also nice would be the possibility to let Denise fetch the colour information on its own, by providing a special first line on top of the screen data (or elsewhere).
This line would simply contain all colour register data, concatenated.
So you would just need to change one pointer to the beginning of that line.

Also mask feature (on bitplanes) could be nice (similar to EGA/VGA).

can you elaborate this?

Copper could have own local (rather small like 32kW) RAM (accessible by CPU directly or indirectly) thus able to perform own program without competing with Blitter and CPU.

You can add local RAM accessible by CPU directly or indirectly to store SPRITE data (thus no longer demand main RAM cycles - like 64kW - such small RAM is typical for FPGA - name it as SPRITE CACHE)

sure.
All this is no problem today, but far beyond the availably space on the chips back than...
Good idea for Vampire or Minimig, but not exactly a missed opportunity.

[sandruzzo]

What about having chip register outside dma bus, and have trap door ram outside too and to blitter and copper access to it?

[pandy71]

Originally Posted by Gorf

not sure if I understand you here correctly....
I guess you do not mean 32 thousand registers, do you? But 15bit wide registers that allow 32k different values?

Why not? why not 32768 or 65356 24 bit color registers where lower part (up to 6 bits) is controlled traditionally (i.e. by bitplane data) and higher bits are controlled by Copper?

Originally Posted by Gorf

Would limiting the copper to higher bits make things really faster? How?

Nope, it will provide minimum compatibility with old applications

Originally Posted by Gorf

due to the 8bit wide RGA bus the Amiga can only address 256 registers in total .... this should habe been changed for AGA by adding one or two extra lines ...

Nope - you have un-populated registers DFF1F0 to DFF1FA (some of them was planned to be used by NewPaula) using only 2 of them you may achieve 65356 new 16 bit registers so in total you can easily add to existing custom chip registers set of 196,608 new 16 bit wide registers addressed indirectly) I believe this is implemented in Indivision by Jens Schönfeld - my assumption based on some general details is that Jens added on top existing functionality a set of new registers to deliver new functionality with "old" data.

Originally Posted by Gorf

True.
Also nice would be the possibility to let Denise fetch the colour information on its own, by providing a special first line on top of the screen data (or elsewhere).
This line would simply contain all colour register data, concatenated.
So you would just need to change one pointer to the beginning of that line.

I think this is a way to feed color and program data to all external video modifiers like DCTV or E-HAM - some lines are used as data carier.
Easily you can extend this idea to provide 16 bit audio in Amiga - sacrifice part of screen and use it as serial line with 16 bit audio (gaining some blitter acceleration as a bonus). 24 lines of hires @2 bitplanes is sufficient to deliver 48000 16 bit stereo audio.

Originally Posted by Gorf

can you elaborate this?

You can imagine mask or even simple ALU set for every bit to perform basic operations on real data stream, i assume new chipset would have all Agnus, Denise, Paula in 1 place thus you can perform for example mask on write (only desired bits can be modified), in EGA/VGA by setting masks you can modify particular bits on all bitplanes.
https://swag.outpostbbs.net/EGAVGA/0079.PAS.html

and

Originally Posted by [URL="https://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter"

EGA[/URL]]
They are bank-switched and only one plane can be read on the CPU bus at once, although the programmer may set the control registers on the EGA card to select which planes are written to. Thus, it is possible to write to all of them at once even though just one plane can be read from at any given moment.

Another step is to simulate some functionality unique for graphic RAM (like pattern application, solid color fill, clear etc such features was implemented on for example SGRAM).

Originally Posted by Gorf

sure.
All this is no problem today, but far beyond the availably space on the chips back than...
Good idea for Vampire or Minimig, but not exactly a missed opportunity.

Today they can be easily integrated on same silicon but in past they could be implemented trough external interface - such 32k CLUT is around 44 pins and 3 8 bit fast SRAM devices (like those used for cache in past).

Originally Posted by sandruzzo

What about having chip register outside dma bus, and have trap door ram outside too and to blitter and copper access to it?

This is not a problem RGA is internal chipset BUS and in FPGA/ASIC can remove any serious limitations on this, RAM clock is limitation for classic Amiga - memory clock is only 3.5MHz, very limited, with modern DDR RAM it can be easily improved by factor 100x virtually you can unify CHIP and FAST on same RAM without severe bandwidth loss.

[Gorf]

Originally Posted by pandy71

Why not? why not 32768 or 65356 24 bit color registers where lower part (up to 6 bits) is controlled traditionally (i.e. by bitplane data) and higher bits are controlled by Copper?

The more registers the slower the access time.
This "register" would be 192KB ...

To access a value you would need a 16bit address - so you would use a 16bit deep screen mode to provide 24bit ...
Changing these 65k registers is costly - and all simply seems not worth it.

It would have been impossible with old technology and with new technologies you have more than enough bandwidth and RAM to drive 24bit, 32bit or even more directly.

Nope - you have un-populated registers DFF1F0 to DFF1FA (some of them was planned to be used by NewPaula) using only 2 of them you may achieve 65356 new 16 bit registers so in total you can easily add to existing custom chip registers set of 196,608 new 16 bit wide registers addressed indirectly) I believe this is implemented in Indivision by Jens Schönfeld - my assumption based on some general details is that Jens added on top existing functionality a set of new registers to deliver new functionality with "old" data.

how are indirect registers any better than banking? That is just an other name for the same thing.

I think this is a way to feed color and program data to all external video modifiers like DCTV or E-HAM - some lines are used as data carier.

yes

Easily you can extend this idea to provide 16 bit audio in Amiga - sacrifice part of screen and use it as serial line with 16 bit audio (gaining some blitter acceleration as a bonus). 24 lines of hires @2 bitplanes is sufficient to deliver 48000 16 bit stereo audio.

interesting idea ... some buffers and you probably could drive an off the shelf audio-DAC with that.
(that reminds me of this 5th audio channel idea using the composite-video port as audio-out and displaying black and white stripes...)

You can imagine mask or even simple ALU set for every bit to perform basic operations on real data stream, i assume new chipset would have all Agnus, Denise, Paula in 1 place thus you can perform for example mask on write (only desired bits can be modified), in EGA/VGA by setting masks you can modify particular bits on all bitplanes.
https://swag.outpostbbs.net/EGAVGA/0079.PAS.html
Another step is to simulate some functionality unique for graphic RAM (like pattern application, solid color fill, clear etc such features was implemented on for example SGRAM).

I see.

I was playing with some idea in my head that is quite similar:
using VRAM (SGRAM ist too "new" for me ) but not to feed Denise, but using the 2nd VRAM-port for Blitter-Operations. Even old VRAM had some internal masking features and simple logic operations build in - often unused by PC_GFX-cards back then...

Today they can be easily integrated on same silicon but in past they could be implemented trough external interface - such 32k CLUT is around 44 pins and 3 8 bit fast SRAM devices (like those used for cache in past).

see above - while certainly possible to implement now, I still can not see that such a mode would be very useful ...

This is not a problem RGA is internal chipset BUS and in FPGA/ASIC can remove any serious limitations on this, RAM clock is limitation for classic Amiga - memory clock is only 3.5MHz, very limited, with modern DDR RAM it can be easily improved by factor 100x virtually you can unify CHIP and FAST on same RAM without severe bandwidth loss.

The "problem" is that today is so endlessly much possible ... so that's why I tried to constrain my thoughts on rather small modifications - preferable within the possibilities of the original technology-level.
But that's just me

[sandruzzo]

since amiga have 6 planes, why don't allow blitter to do 6 blit operations in one shot whitout cpu aid? What about interleaved blit made in Hardware?

[sandruzzo]

-Copper burst(multimove)

- (Copper move next) were you tell how many move you want to do, what register to start and offset to next register, that can be "0". Make copper 2 stage chip, so you can load and execute like blitter and make it able to use all cycles

[pandy71]

Originally Posted by Gorf

The more registers the slower the access time.
This "register" would be 192KB ...

Nope - this will be pair of registers - address register and data register.
Access time doesn't change (except it require 2 cycles)

Originally Posted by Gorf

To access a value you would need a 16bit address - so you would use a 16bit deep screen mode to provide 24bit ...
Changing these 65k registers is costly - and all simply seems not worth it.

Yes and no, first we talking on first 16MiB space (ZorroII) that must remain 16 bit to provide compatibility with legacy software, there is more than desired to create 32 bit register area accessible directly in ZorroIII space.
Same registers but accessible in two locations - 16 bit and 32 bit (or more).

Changing register indirectly is not costly, this is common way to deal with large register set inside chip.
Amiga RGA access is slightly different as address was used also as strobe to trig particular action - for example Amiga video timing is controlled by sequence of address operation on few registers (STREQU, STRVBL, STRHOR, STRLONG).
If you not extend amount of registers then you can't implement new features - this is very simple - large CLUT can remove serious limitations of Amiga (OCS/ECS have 6 bitplanes but due only 32 color LUT is unable to use 6 bitplane directly - only EHB/HAM works - this is clear proof that extending set of CLUT entries plus adding efficient way of switching them with Copper can be very useful extenssion)

Originally Posted by Gorf

It would have been impossible with old technology and with new technologies you have more than enough bandwidth and RAM to drive 24bit, 32bit or even more directly.

This was possible with old technology but costly due large bus width required (also could be workarounded by using fast serial bus like nowadays). Memory interleaving, double (implemented since A3000) or quad bus, new techniques (like FPM,EDO,Nibble,Static Column etc).

Originally Posted by Gorf

how are indirect registers any better than banking? That is just an other name for the same thing.

Indirect doesn't change existing address space, banking allow quickly switch whole set of registers.

Originally Posted by Gorf

interesting idea ... some buffers and you probably could drive an off the shelf audio-DAC with that.
(that reminds me of this 5th audio channel idea using the composite-video port as audio-out and displaying black and white stripes...)

Yes, single 48kHz 16 bit require 24 (2 bitplane 640 pixels 25 Hz) lines with normal 640x400 screen you could have up to 6 independent 48k 16 bit channels and still retaining useful screen (like 2 color Atari ST mono)
If you code data on 4 bitplanes then you can increase amount of data.
Easy to extract as TTL 4 bit output is present.
Add to this simple commands, use few lines to sent some VBI data and even in 1989 Amiga could easily compete with some music workstations and in TV studio.

Originally Posted by Gorf

I was playing with some idea in my head that is quite similar:
using VRAM (SGRAM ist too "new" for me ) but not to feed Denise, but using the 2nd VRAM-port for Blitter-Operations. Even old VRAM had some internal masking features and simple logic operations build in - often unused by PC_GFX-cards back then...

First gen of VRAM doesn't offer too much except this two channel.
With SDRAM flexibility is way higher on single channel.

Originally Posted by Gorf

see above - while certainly possible to implement now, I still can not see that such a mode would be very useful ...

Easy, load 128KiB to CLUT, display pixels, use copper to switch CLUT instead feed CLUT - single Copper write is able to switch 16/32 (64/128/256 on AGA) colors at once, every screen can have local CLUT with single Copper etc.

Originally Posted by Gorf

The "problem" is that today is so endlessly much possible ... so that's why I tried to constrain my thoughts on rather small modifications - preferable within the possibilities of the original technology-level.
But that's just me

IMHO all my proposals fit in old technology level - they was feasible in 1985 but simply more costly than today, also they are legacy compatible.

For new approach i would change everything fundamentally - use external graphic chip as main screen (also providing flicker free operations) and external Amiga chip data fed to single window overlays on new screen - this remove most of incompatibility (except genlock to some point) and most importantly remove limitations from Amiga chipset.
For example you could imagine RGB data from Amiga fed as "camera" data over CSI bus to new display (RPi is capable to do such thing and you can have everything at once - new graphic card, flicker fixer, 3D, CPU, network, USB etc at cost of RPi and CSI serializer like http://www.lontiumsemi.com/?thread-2488-1.html )
you can go further and use RPi as CPU (CPLD to emulate 68k bus) with software (JIT) 68k emulated on ARM.

Originally Posted by sandruzzo

since amiga have 6 planes, why don't allow blitter to do 6 blit operations in one shot whitout cpu aid? What about interleaved blit made in Hardware?

You can do blit ops on 6 bitplanes in one shot.

Originally Posted by sandruzzo

-Copper burst(multimove)

- (Copper move next) were you tell how many move you want to do, what register to start and offset to next register, that can be "0". Make copper 2 stage chip, so you can load and execute like blitter and make it able to use all cycles

This will change Copper ISA as such remove compatibility with legacy software.
It is way better to create new Copper (at least 32 but better 64 bit wide) able to do new things in single cycle. Perhaps not using main RAM at all (own, proprietary RAM to keep Copper instruction and data but accessible to CPU trough DMA or MMU protected address area).