Thanks for your enthusiastic response!
Some valid questions have been brought up here, which I am going to respond to.
How does this mode work? And where is the difference between this and the Grafitti mode?
As some people correctly pointed out, 320x200 in 256 colours is also possible in Grafitti mode. However, there is one very important difference. In order to display a 256 colour picture under Grafitti, one has to open a hires screen in 16 colours. Those, who know a bit how the Amiga chipset works, immediately realize that under OCS/ECS, any 16 colour hires screen causes Agnus to reserve all available memory slots for display DMA. That means, the CPU can only access the Chip Ram during the horizontal and vertical blanking interval, which effectively reduces memory bandwidth from 3.5 MB/s to under >1MB/s. If you have ever wondered why Deluxe Paint was always unbearable slow in hires 16 colours on an A500 without fast ram, this is the answer. The result is that Grafitti mode is not really useful for games on OCS/ECS machines, especially on 68030+ CPUs, where a chunky/planar routine is faster.
The new Indivision GFX mode (which btw. was introduced with V1.0 firmware) works completely different. Here, the Amiga video is completely disabled (as you can see in the first picture). Instead, the CPU writes directly to the 8MB SDRAM chunky framebuffer of the Indivision ECS flickerfixer. Since the Amiga display DMA is completely turned off, we get a 256 colour chunky screen with full 3.5MB/s access to it, exactly like a Zorro II graphics card.
Of course, this method has certain restrictions since the 8MB SDRAM is not memory mapped. Instead, you can only access it by setting up a write address and writing the data directly to a register, while the FPGA autoincrements the video address.
That means, in any case, where a game or application renders its display in fast ram, and then copies the result into the graphics memory of the graphics card, Indivision ECS is an equivalent replacement to a Zorro II graphics card. Whether I do a move.l (ax)+,(ay)+
or a move.l (ax)+,(ay)
is completely irrelevant since it's the same speed. So, 3D games with software rendering can have the same speed on Indivision ECS than on a graphics card. Which is especially important on small Amigas without slots, like the A600. The upcoming ACA630 has a very fast interface to fast ram and chip ram.
Is there any API available? Is it possible to add native RTG support?
Currently, there is no API available. Since the framebuffer is not directly mapped into the Amiga memory map, a context-independent implementation is quite challenging. Any RTG driver would first have to render all pixel operations to fast ram, and then copy it into the SDRAM framebuffer. The only way I can imagine how this could be fast enough would be to copy only the display areas, where something has changed. One could imagine a graphics driver using the MMU to split the memory into segments. This is how some Shapeshifter video drivers work. Realistically, this would be a quite ambitious project, far exceeding the amount of work implementing support for Indivision ECS in various games. We'll see about that. At least, I already implemented a hardware sprite for a mouse pointer in the Indivision GFX core.