|
Post by Casethecorvetteman on Aug 5, 2015 21:08:47 GMT -5
29 lines might almost be acceptable.
|
|
|
Post by barclay66 on Aug 6, 2015 4:15:50 GMT -5
Hi,
I have an idea for a device which should be able to reduce lag to two lines max. I've put together a block diagram which shows all functional elements needed. Is there any way of uploading/including an image into a post? There's an "Add Attachment" button but it doesn't do anything and I don't want to use any external picture hoster...
Regards, barclay66
|
|
|
Post by Admin on Aug 6, 2015 8:33:18 GMT -5
Hi, I have an idea for a device which should be able to reduce lag to two lines max. I've put together a block diagram which shows all functional elements needed. Is there any way of uploading/including an image into a post? There's an "Add Attachment" button but it doesn't do anything and I don't want to use any external picture hoster... Regards, barclay66 Odd that your add attachment button does not do anything. It works fine whenever I use is. You can also use the "add image to post" button in the upper left corner of the white box of either the quick post or regular post. Of course the "add image" uses an external host but it is through the forum. Quick post: Add attachment:
|
|
|
Post by Casethecorvetteman on Aug 6, 2015 21:21:25 GMT -5
Hi, I have an idea for a device which should be able to reduce lag to two lines max. I've put together a block diagram which shows all functional elements needed. Is there any way of uploading/including an image into a post? There's an "Add Attachment" button but it doesn't do anything and I don't want to use any external picture hoster... Regards, barclay66 That would be excellent if it can be done
|
|
|
Post by barclay66 on Aug 7, 2015 3:05:14 GMT -5
Hi,
This is just an idea which is based on several schematics for line doublers that I 've been studying. Here's its theory of operation:
Line-based digitizing of the video signal
The red, green and blue video signal are digitized through individual analog to digital converters. The conversion rate needs to be matched to the input resolution. So if the input format has a horizontal frequency of roughly 16KHz we get 62.5µs for a complete line. If each line has 320 pixels we get 0.195µs per pixel which results in a minimum conversion rate of 5.12 MHz. Going higher will give room for slightly higher input resolutions. Going lower will result in loss of picture information. Ideally the conversion timing would be related to the horizontal sync signal. A/D conversion control isn't shown in the block diagram yet.
Line-based memory (line buffer)
The horizontal sync impulse (indicating the beginning of a new line) is used as a reference for a frequency multiplyer (PLL generator) and its output controls the write enable of a dual-ported RAM. As the name indicates, a dual-ported RAM has two independent access ports to its memory cells. So you can write onto the same cell from one port as you're reading from the other port. In addition, the writing/reading speed at the two ports is independent from each other and limited by the device's general access timings only. So, multiplying the horizontal frequency with the expected number of pixels per line will result in an exact digital copy of a line's content into memory. Therefore we can call it a line buffer. The size of the memory device will be fairly small as we need one byte per colour and pixel only (at a horizontal resolution of 320 pixels we would need 3 x 320 bytes). For reading the memory content at the other port we use another frequency multiplier's output (this time multiplied by two) as a control signal. So each line gets read two times. Maybe the memory will need to be doubled in order to prevent that new input signals overwrite the memory cells before they have been read twice. So the output reading system would toggle between the two line buffers. This would add a lag of one line. What is missing in the block diagram is a more detailed elaboration of the address counter and memory peripherials.
Output signal generation
Once the line buffer is read, three digital to analog converters produce an analog output signal for each color. The conversion rate here is exactly twice as high as on the A/D conversion side. D/A converters with a bandwith of more than 10MHz will be required. Maybe a passive (R2R) version could be suitable. In order to blank each second line (we don't want line doubling but scan doubling!) the memory read control signal is divided by 320 (yielding the new horizontal sync signal, now twice as fast as the input signal) and fed to a two-stage binary counter. It's MSB (most significant bit) output will be toggled at each second line and this signal controls three fast analog switches which connect the video outputs to ground, thus blanking each second line. This part of the block diagram is missing some details like the binary counter and the video output amplifiers.
I can imagine that someone could create this inside some FPGA or similar device but I can't. I would try to build this with conventional hardware...
Regards, barclay66
|
|
|
Post by Casethecorvetteman on Aug 8, 2015 21:54:06 GMT -5
All sounds very technical, but promising none the less
|
|
|
Post by Casethecorvetteman on Sept 6, 2015 0:51:00 GMT -5
Ok so after testing the XRGB3 the guns do now work... However...
Theyre not accurate.
The reason for this is an unavoidable issue, the fact is that the line is drawn twice as fast as the console sends it to be drawn, so when the gun sees the light, it is further to the right of the screen than the console expects it to be, hence a significant distance from where youre pointing the gun.
There is no way around this that i can forsee, the 15.7kHz rate is a must.
|
|