Hello Jens,
By looking at the picture with the 3 screens, I can see that the dual screen trick is done this way :
The Amiga (I mean Agnus...) is set up to display a 640x512 interlaced screen but the workbench thinks it is a 1280x256 screen.
One FF shows the even frames, the other one shows the odd frames. Screen update is done at 25Hz in the FF's SDRAM and 75Hz on the screens.
Very smart trick indeed.
Thanks :-) That was only the fastest possible way of testing the thing, and there are multiple other ways to transfer different pictures.
To get higher resolutions, you will have to lower the update rate. It reminds me the high resolution screen from commodore that was combining 4 screens and had an update rate of 15 Hz.
You're talking about the A2024 monitor - nice thing, I have been using that over many years until the CRT stopped working. It did have some nice additions like transferring the field where the mouse pointer is more often than the other fields, so it appeared to the user as if the update rate was higher. A serious drawback was that it could only display five or six different shades of grey. I do like retro, but black&white is not the right thing for the Amiga (even for people like me, who do everything in the shell).
Back to the indivision, a good use of it would be to get HW acceleration for MAME.
If it is possible to reconfigure the FPGA on the fly without flashing the board, that might be possible (I do not want to reflash the board each time I play a different game).
Re-configuring from software-only without going through the flash may be possible, but will have to stand back behind a fast re-config from flash. We may have to switch between FPGA cores on every change of screenmodes, so speed is cruicial here. Currently a change of cores takes about a tenth of a second if flash is the source, but we'd like to reduce this to "one VGA frame", so monitors don't get confused too much.
Re-configuring from software-only will take a lot longer (several seconds), as there's only a bit-banging data path to the FPGA. I will probably NOT release the schematics to this thing, as it's meant to be a product, not a development platform, so don't count on anyone to make specialized cores for non-standard software. Imagine somebody causing bus contention between the 3.3V FPGA and the 5V-tolerant drivers! A faulty core could potentially damage a chip, and if this happens within the warranty period, it would be very expensive for me. The risk is just too high.
Jens