Heh. While doing a quick Google I happened to run into your thread on the Parallax.com forum, and it looks the last answer in that forum is basically what I was suggesting, other than referencing code that supposedly should be able to do the sampling without an external shift register.
If you were to follow that person's suggestion and make this a simple "scan doubler" (IE, essentially stretch the 512x342 display to 512x684 with a 44.5-ish khz horizontal scan rate) then I suppose it's worth pointing out that you don't even need to digitize the whole display. Two lines should be enough, since input and output will be operating in lockstep. (You'd read one line from the input, and then while reading the next line the output cog would display the previous line twice in the same amount of time.) Hypothetically this reduces your hub-RAM requirement to a whopping 128 bytes. (Or maybe a bit more, since you could simply scan the "front and back porches" as black pixels and use the Hsync pulse as an "end of line" signal. The longer Vsync pulse could be used to sync the the frames.) A scan-doubled display like that should work fine on a multisync CRT monitor and might be dead easy to program, but a VGA LCD monitor's scan converter might not like it. If you plan to convert to a more "standard" field/scan rate then you probably do need to grab the whole frame, or at least a good chunk of it, and distinguish the blanking intervals from the actual signal.
Out of curiosity, did you ever make any progress on your thread about using an FPGA and an LCD display?
If you were to follow that person's suggestion and make this a simple "scan doubler" (IE, essentially stretch the 512x342 display to 512x684 with a 44.5-ish khz horizontal scan rate) then I suppose it's worth pointing out that you don't even need to digitize the whole display. Two lines should be enough, since input and output will be operating in lockstep. (You'd read one line from the input, and then while reading the next line the output cog would display the previous line twice in the same amount of time.) Hypothetically this reduces your hub-RAM requirement to a whopping 128 bytes. (Or maybe a bit more, since you could simply scan the "front and back porches" as black pixels and use the Hsync pulse as an "end of line" signal. The longer Vsync pulse could be used to sync the the frames.) A scan-doubled display like that should work fine on a multisync CRT monitor and might be dead easy to program, but a VGA LCD monitor's scan converter might not like it. If you plan to convert to a more "standard" field/scan rate then you probably do need to grab the whole frame, or at least a good chunk of it, and distinguish the blanking intervals from the actual signal.
Out of curiosity, did you ever make any progress on your thread about using an FPGA and an LCD display?