Steve Anderson wrote:Now then Guys and Gals....
Attached is a conceptual hardware implimetation of the above. What I don't know is...
1) Can the PC keep up with the required data rate through the paralell port? This of course is dependant on the PC hardware.
2) Using Interrupts, how precise would the timing be? i.e. would the buffer/latch be needed? What is the latency within the interrupt routine?
3) Could this be expanded to four bytes at 48kHz? One for luminance, two for colour-difference channels, and one for 8-bit audio? This of course would require additional external harware.
Andrew, Gary, over to you, I'm no programmer...
As shown the gate produces sync only when the data is 00h, if changed from an OR gate to a NAND gate, then FFh would generate the syncs.
Steve A.
Steve, a PC is generally well able to keep up with this rate *providing* it is not running windows or a windows like OS, for instance DOS is fine.
However...
Now Ralph Taggart has designed a very nice parallel port NBTV input device (i.e. the reverse of what you are proposing):
http://taggart.glg.msu.edu/ich/nbtvcpu.htm
Which has a nice DOS interface. He asked if anyone was interested in developing a windows interface to this device and I took it up (perhaps a little optimistically).
I knew that the only way to approach this was to write a device driver since this is the only way to gain the exclusive access to the system that is needed to obtain the throughput - sans buffering (even a relatively small amount of buffering solves the problem otherwise). Of course when in video capture mode there would be no time left to service other window applications but when you've got a wonderful NBTV application running who cares?
This works well in terms of being able to process the video information. I have a prototype that takes the information in and displays it very well (keep in mind that the reverse process is even easier). Where I have come to a road block, rather infuriatingly, is that whilst in video capture mode there is no way to service mouse and keyboard events. That is not to say there isn't enough time to do that, because there is.., unfortunately, the standard drivers for mouse and keyboard do not work well with other device drivers, especially ones that are running at a much higher priority. I initially thought that I would, in kernel mode, be able to access the keyboard hardware directly, and in fact I can, but for some reason that I am not yet aware of this is unreliable. I thought that I would eventually stumble over a simple solution for this, but two years later I have still failed to do so. I could, of course, write a new keyboard device driver, but this is a major undertaking, and means the existing driver needs to be uninstalled so I would run the risk of disabling the OS if something went wrong.
Technically, I think it is possible to solve this problem, and I have not given up on it, just placed it on the back burner waiting for some critical piece of information to turn up. Strangely, no one else seems to have attempted to tackle this problem.
The other disadvantage of this method is that different OS's (i.e. 95, 98, NT, XP 2000, and now Vista) generally need different Device Driver paradigms and so there is no 'one size fits all' solution, however I felt that a solution that worked for NT, 2000, XP would be worthwhile as 95 and 98 can easily run the dos programme as it is.
Vista is another beastie all together but in fact it should make the device driver easier to create.
So as it stands it is possible to sustain the data rates under windows so long as you don't need to control it
If anyone out there has any ideas on the subject I would be very grateful indeed to hear from them.