Test NTSC video frame
potatohead
Posts: 10,261
Got somewhere. Not far. I need to know a lot more about the STREAMER and DAC modes, but hey! It's a nice frame. Yes, the code is ugly. Was focused on timings and sync... both of which could be a lot better, but this should display on most devices. I'm curious as to whether it does. Connect composite to DAC 0.
Comments
I was looking to carve out a rough signal by just plugging values into the DACS directly. Not knowing much about the STREAMER, etc... it was a first step. From here, I plan to consolidate things, test for jitter, see what HUBEXEC does, and so forth. But there needed to be a baseline signal to work from and gawk at on the scope.
Without WAITVID, I think a good signal foundation is going to need to be interrupt driven so it happens on time, every time, no matter what. Ideally, pixels are bursts from the STREAMER, triggered by key time events in the signal. A driver template would more or less be some code, with a "put your pixel code here" kind of thing in it. Similar to P1, but a bit more complicated to create baseline signals.
Again, ideally not so complicated for people to provide pixels however they want to do that. Scanline driver, bitmap, etc...
Use as an object should be very similar to P1.
Then again, Chip may have a much better plan. Maybe it can be simpler than I envision.
I hope there's a way to use the streamer for this. Think that means finding a way to throttle down the transfer speed. Otherwise, I guess we'll have to stream to LUT and then push out from there.
IIRC, Chip has said the streamer has a NCO clock scheme ? (including /1).
I'm not sure if that means there is a /N as well as a NCO adder, as both have uses.
NCO is good for granularity and matching average rates, but it can give jitter for non-binary adder values.
/N clock control is jitter free.
Ok, Ill snap a photo of my old amber screen, signal notes, etc... Monday for you. I will add the notes because they will be more interesting than the video will be. :j
I've found you can get good divide-by-N performance for billions of cycles (before an imperfection) with an NCO by using an adder value of maximum/N+1.
Take 1/3, for example, in a 32-bit NCO. 1/3 = $55555555. If you don't add 1 to it, it won't roll over until the 4th add, then on every 3rd, thereafter. By using $55555556, instead, you get a rollover on every 3rd add, right from the start. Every few billion adds thereafter, you will get a rollover in only two adds, instead of the usual three. This anamoly will rear it's head long after a scan line, or something similar, has finished.
Sounds like you do not have a /N choice from that reply ?
I can see the earlier disturbance is removed, but the longer-term issue remains...
Let's consider 120MHz -> 40.000MHz
120M/(2^32/0x55555556)-40M
= 0.0186264514923095703125 Hz error (high)
53.687 s disturbance rate,
instead of 25.000ns, one period is 16.667ns
120M/(2^32/0x55555555)-40M = -0.00931322574615478515625 (low)
107.374 s disturbance rate
instead of 25.000ns one period is 33.333ns
A monochrome TV may not notice this, but there are other clocking systems where such a phase disturbance is going to be quite nasty.
The Transfer NCO's phase can be reset on scanline start using XZERO, as opposed to XCONT, so that any would-be anomaly gathering in the LSB'S can be zero'd out. In practice, those periodic disturbances can be avoided.
XINIT D/#,S/# transfer init, reset phase
XZERO D/#,S/# transfer update, wait for rollover, reset phase
XCONT D/#,S/# transfer update, wait for rollover, continue
I didn't see them in docs...
SETXFRQ is the streamer's freq for its NCO. If the MSB is set, it will cause the streamer to fire every clock. So, it's like FRQA, but with an MSB that allows 100% firing. I need to document that, of course. In the FPGA files I just posted, there's a "sin_cos_dacs.spin" program that uses it to generate sine/cosine waves.
Ok, I think I understand it now... Looks like there are two different things called "Streamers"... One is to/from HUB and one is from LUT to DACs.
Being just a test, the code is really simple. Not much in there at present. Not much to change...
A7 output is dimmer than DE2 because of different DAC configs.
Video output is on DAC2 on A7 board.
DAC labels on A7 board are a little confusing.
The schematic refers to DAC0 and DAC1 yet the board overlay refers to DAC's 0 to 5.
Chip mentioned this will be rectified on A9 board