To start you all off, I will present my own thoughts on what could possibly improve the shifter dramatically, with literally no incompatibility with existing software, avoiding high colour mode sluggishness and very little in the way of achitechtural changes to the chip.
This was originally a conversation I was planning to have with @Icky , so it saves me repeating myself, I suppose! ;)
I'm thinking of an 'on-shifter' version of a DCTV (or the similar HAM-E) based device.
**** Now, before I get too far, I have to admit, I do not know much about PAL/NTSC video standard encoding, so will be referring to an article (*1) that explains how the below featured concepts work, for anyone who DOES actually know enough about these video standards to understand what is being done. I am also describing the device methods of operation as far as I am able to. I may have overlooked or mistaken some details. ****
Moving on then...
The unit is an external video device which lays dormant and basically acts as a 'Video thru' device until a 'magic cookie' type output signal sequence is intercepted in the top raster. When present, this then activates the unit to start its processing and decode the screen image (which has now been replaced with the magic cookie and a specially encoded bitpattern type image).
This then takes data from the image bit patterns (think of something similar to how a C64 screen processes the bit positions when switched to multicolour mode, if that helps visualise) and a separate RGBI input of the same image (output on the Amiga's Video output pins) and decompresses it into the external HW for display.
The above image showing the integration of 'ordinary' 4bpp screen with the enhanced image higher in the frame with the extra colour content.
The above image goes some way to explain things.
Unfortunately, that's as far as I can explain, as I don't have in-depth knowledge about how they decompress and encode the PAL/NTSC data from the input. But I've linked to an explanation by one of the guys who created it. (*1) I'm hoping you guys, who create video HW will have more of a clue! :)
The missing ingredient to this, that you WILL have to provide, is the lack of concurrent RGB+RGBI output from different pins on the ST monitor port (the Amiga seems to have a few extra bits like this; e.g. another one is the mysterious/undocumented UHRES registers which may have been a preliminary building block Video signal for the Ranger chipset which never materialised).
Personally, I would think something like this is a free upgrade, with no arch. upgrades whatsoever needed, other than another video output signal. (I imagine it doesn't even have to be RGBI and possibly using a better video signal type would improve matters?)
24-bit quality games are now within reach, with the same speed as regular 16 colour ones and all previous SW (games OR Apps) are fully compatible still.
There's the possibility of using 2-3 bitplanes for either a much faster display (and not too shabby colour wise either) or for higher resolution displays where a higher colour count is needed in productivity software.
All this, without having to learn any HW specific system device (i.e. much like an Amiga, where the games oriented HW is quite handy, but you have to fall in line as to keeping to its limitations, as opposed to a more open frame buffer based system, which is far more portable I believe; well, it's what's done on an ST anyway, along with loads of other systems.)
Finally, while being inherently lower resolution with its output, the actual output looks crisp enough (the units above have CVID>RGB converters) and IMHO is a far easier option than a bus saturating 24-bit card solution AND the complexity/cost of an 030+/faster wider bus to handle it adequately.
(*1) https://retrocomputing.stackexchange.co ... -dctv-work
Above is the link to the site discussing the workings of the unit, but as I know the management here prefer real data (as opposed to 'tenuous links that could disappear any day'), I have included the engineer's explanation below: ;)
**********************************************************************************************************************************************************
After some research, I found the hardware engineer that built the DCTV and we exchanged some messages where he explained the system.
This is the unedited text:
Wow, it has been a long time... I didn't really remember! Luckily I still have all the lab books and design notes from those days filed away. We used a technique that encoded the data on two consecutive lines in the Amiga frame buffer in a way that we could reconstruct a composite video signal when run through some processing and combined with data from the previous line (delayed through a line memory). I know that is pretty ambiguous, but it is a general description. I will describe in more detail below, but it assumes some familiarity with NTSC composite video signals.
In more detail: Amiga had a frame buffer mode that displayed 736x483 pixels, but only 4-bits per pixel (16 colors). We used that mode, but re-interpreted the data. We combined alternate pixels so that we had 8-bits per pixel at half the rate. Even (I think) lines stored data as Y + (R-Y), Y - (R-Y), etc. [Luma +/- red color difference value, alternating] at a 7.159MHz sample rate. Odd lines stored data as Y + (B-Y), Y - (B-Y), etc. [Luma +/- blue color difference value, alternating], logically shifted by half a 7.159MHz sample. So every line would contain every other raw sample for an NTSC composite video signal. In order to reconstruct the missing data, it would generate the Y component by averaging the values left and right of the missing sample, and the chroma component by subtracting the two adjacent samples from the previous line. The final value was created by adding these values together. The resultant data stream was at 14.318MHz and contained Y+(B-Y), Y+(R-Y), Y-(B-Y), Y-(R-Y), etc. When converted to analog and added sync and so on the resulting signal was a full color composite signal that looked surprisingly good.
So it was really a way to get full color out of the Amiga frame buffer by applying some signal processing techniques to trade off spatial resolution for increased colors. Instead of a frame of 736x483 pixels of 16 colors, we got an effective resolution of about 368x483 pixels of full NTSC type color. Chroma resolution was less (as with any composite NTSC type signal), including somewhat less resolution vertically. But it looked pretty good by 1990 standards! We found that we could even stream data off a fast (for the time) hard drive in real time, and used to demo by playing back scenes from "Back to the Future" at trade shows. Fun times.
Actually we may have used the 704x483 graphics mode... I got he 736 number from Wikipedia, but I am not sure it is correct. 704 sounds more right.
Then me asking a bit more:
You have cleared a mystery that was popping back in my mind now and then! It is true that for the time, the output was very good! so you could probably fit the decoding logic in a cpld?
And he replied:
The decoding logic fit in a 3000 series Xilinx FPGA. The line memory was external, along with the D to A converter and a few other things like a PLL for the pixel clock. I think the final product had an A to D converter for grabbing images from an external video source as well...
