This is a hardware-related issue. I have spent about 6 hours now searching the www but so far no luck. Maybe one of you knows the answer? I am trying to find out on which raster the VIC-II generates the vertical sync on an NTSC machine. My experiments reveal it is somewhere around raster 11 and is 3 rasters long. It would be nice to know for sure so I can perfect my new video mode.
I say new because I have read many articles on the VIC-II(e) (which gave me the idea) but have never seen anybody do it or even claim to do it. I've only got one TV to test it on, and nobody nearby I know has a C128 for testing. I may break down and lug my new commie over to a friend's for testing. I'm sure none of them would be willing to lug their TV over to my home :)
If you haven't already guessed, I'm talking about 320x400 (or 160x400) interlaced video. I've got it to work on my TV but since it breaks the NTSC standard it may give others trouble. On the other hand, the VIC-IIe, itself, doesn't strictly follow the standards.
An encouraging sign is the tuner in my TV is digital, and will blue screen if it gets a signal it doesn't like (as I discovered when goofing with the VDC interlace mode), but so far I haven't got the 'blue screen of incompatiblity' :tummenupp: I have managed to completly kill the vsync resulting in a nice rolling display which is where I got my raster 11 estimate from.
So far I've only discovered what I already (mostly) know, that there is about 5 rasters of vertical blanking before the sync, the sync is 1 to 3 raster long, and there is another 5 to 10 rasters of blanking afterwards. The exact values vary by sources of read and refer to NTSC in general or VGA-specific. Interesting, but doesn't tell me where VIC creates his vsync.
So who knows?
Perhaps you've been here already, but just in case, I'm posting it (because of the irregular location of the file (under cbmpics) which makes me assume i'll be seeing pictures, not text file ;-)...but so far, it's the most complete vic-ii text file I've seen to day. seems to cover a whole lot of vic-ii data.
http://zimmers.net/cbmpics/cbm/c64/vic-ii.txt
is you did see it already...i'll continue to search :-)
Thanks for the link. I haven't seen that one today but it looks familiar... I'll let you know if I find the info.
Not in there, bummer.
I found this link which might interest you. it's entitled "Making Stable Raster Routines" it's for the C-64 and VIC-20 but hey, It might be useful :-).
http://www.antimon.org/dl/c64/code/stable.txt
Let me know if that has your answer. :-).
Also, this might be interesting :-)
Typical Values
(decimal)
$E880 $E881 Text Graphics
+------+-------------------------------+
| 0 | Horizontal Total | 49 49
+------+-------------------------------+
| 1 |Horizontal Characters Displayed| 40 40
+------+-------------------------------+
| 2 | Horizontal Sync Position | 41 41
+------+---+---+---+---+---+---+---+---+
| 3 | V Sync Width | H Sync Width | 15 15
+------+---+---+---+---+---+---+---+---+
| 4 |///| Vertical Total | 32 40
+------+---+---+---+---+---+---+---+---+
| 5 |///////////|V Total Adjustment | 3 5
+------+---+---+---+---+---+---+---+---+
| 6 |///| Vertical Displayed | 25 25
+------+---+---+---+---+---+---+---+---+
| 7 |///| Vertical Sync Position | 29 33
+------+---+---+---+---+---+---+---+---+
| 8 |///////| Mode | 0 0
+------+---+---+---+---+---+---+---+---+
| 9 | Scan Lines | 9 7
+------+-------------------------------+
| 10 | | 0 0
+------+- - Cursor Start (unused) - -+
| 11 | | 0 0
+------+---+---+---+---+---+---+---+---+
| 12 |///////| C | R | Display | 16 16
+------+---+---+---+---+- - - -+
| 13 | Address | 0 0
+------+-------------------------------+
NOTES: 1. Registers are write-only.
2. Avoid extreme changes in Register 0. CRT damage could result.
3. Register 0 will adjust scan to allow interfacing to an external
monitor.
4. Register 12, Bit 4, will "invert" the video signal.
5. Register 12, Bit 5, switches to an alternate character set. The
character set is not implemented on most machines except
SuperPET.
Thanks for trying but none of these documents tells us where the VIC generates the vertical sync. I think this undocummented behavior is why nobody has done interlaced video before. I thought about opening my commie and connecting the vertical sync to the interrupt line so I could catch it and know for sure, but the VIC only has two video outputs, color and lum/sync so there goes that idea. A 'scope would be nice :)
I'll make a demo with my 'best guess' and then others can see if it works for them.
Update
According to my experiments, the following is true for NTSC VIC-IIe
Vertical blank starts on raster $0D (13) and lasts 4 rasters
Vertical sync starts on raster $11 (17) and lasts 3 rasters
Vertical blank continues on raster $14 (20) and lasts 4 rasters
VIC generates even fields
Since these are even fields, the rasters correspond to NTSC rasters 2,4,6,8 etc. Which means you might have difficulty trying to do teletext / closed captioning as somebody suggested in another thread. Closed captioning, at least, is encoded on line 21, an odd line!
When fudging VIC to produce odd fields (only), I noticed a slight color artifact. I've read somewhere that the color burst should be 180 degrees out of phase between the two fields, which to me, seems like the colors should be all wrong but they are not... (could be trouble for PAL though). Also, I have VIC connected with composite so the color artifact may not present using seperate luma and sync (S-Video). It's very subtle, I would have to call it color smearing.
Several methods produce interlace video, but often the rasters are not quite aligned. It seems my TV will remove rasters from the bottom of the screen if I cut them from the initial vertical blank, line $10 (16), or sooner; and will remove rasters from the top of the screen if I cut them from the v-sync, line $11 (17), or later.
When the rasters are cut 'right' there is jitter as you might expect with interlace video, but it is quite subtle (compared to the VDC). So subtle in fact, I wasn't even sure it was interlace so I made a BIG circle demo. It consists of 2 hi-res bitmaps both of which resemble a circle but in each there are missing segments. In other words, neither of the two bitmaps is a circle but... turn on interlace and switch between the two and viola, a super-smooth 320x400 circle.
I'll get the demo available for you folks as soon as I decide on how I'm gonna xfer data to my PC.
In the meantime, PAL folks might want to determine where VIC makes his v-sync. My method of determining blank and sync lines was to kill the v-sync and as the v-blank region rolled by (the whole screen will roll with v-sync killed), I'd look for when border color changes became visible. Of course it took raw experimentation to find out where the v-sync was. You might try code like this
SEI
low LDA D011
BPL low; wait for high rasters, 256+ ... just a guess for PAL
LDA #20 ;experiment with this value
CMP $D012
BNE low
LDA #2
LDX #0
STA $D030 ;turn on 'test' bit, VIC will skip a raster for each cycle
STX $D030 ;4 cycles later, turn off 'test' bit... should have killed 3+3/4 rasters
JMP low ;do it again
Once you get a rolling screen, add code to delay after the STX $D030 and then change the border color. With INC $D020, DEC $D020 for example. Hopefully you get the idea but if you have questions, feel free to ask.
Hmm... it sounds like all the magic takes place during the v-sync, so that means that during the actual frame display you have tons of cycles free, right?
It's great to see something like this born in NTSC land. The PAL people have been dominating VIC trickery for far too long. :P
Quote from: nikonikoHmm... it sounds like all the magic takes place during the v-sync, so that means that during the actual frame display you have tons of cycles free, right?
RIGHT!
My first method steels about 2+1/2 rasters = 156us from every other (even) field(making them odd fields). Thus two fields (one frame) = about 32593.75 us for a complete frame = about 30.7 frames/second.
reason for edit: typed field insead of frame
By the way, have you thought about posting over at CSDb? I'm sure they'd love the idea of new video modes to play with, and could help you refine it. And I'm sure someone there would also love trying to adapt it for PAL. Even if it wrecks havoc with PAL colors, some might consider that useful, especially if it provides new palette possibilities. :)
What is CSDb? Anyway, the demo is ready, available here. (http://sites.google.com/site/h2obsession/CBM/C128/images/Interlace.zip)
Quote from: hydrophilicWhat is CSDb?
It's the C-64 Scene Database (http://noname.c64.org/csdb/).
Thanks for the link! I think I'll pass cuz they want me to set up an account. I have enough accounts as it is :/ More honestly, those are like hip-hop 'scene' demos and my demo would be humiliation there... I mean no jazzy music, no colorful bitmaps, or sprite tricks, no raster bars or scrolling text or anything else of a typical 64 demo.
On topic, I believe some of my conclusions above are incorrect based on some web research today. Specifically,
QuoteVertical blank starts on raster $0D (13) and lasts 4 rasters
...
Vertical blank continues on raster $14 (20) and lasts 4 rasters
Now I have seen various descriptions of the NTSC signal, but consistantly there are 3 special rasters before and after the v-sync. When I posted that, I thought VIC was just fudging a little by using 4 instead.
But now I have a new theory:
Vertical blank starts on raster $0D (13) and lasts 1 raster
Pre-equaliztion pulses start on raster $0E (14) and last 3 rasters
Vertical sync starts on raster $11 (17) and lasts 3 rasters
Post-equaliztion pulses start on raster $14 (20) and last 3 rasters
Vertical blank continues on raster $17 (23) and lasts 1 raster
VIC generates UNKNOWN fields
The equalization pulses consist of black/blank mixed with horizontal sync pulses (blacker than black). In other words they appear black, so hopefully you can understand how I made the error.
Also previously I thought I could tell if it was an even/odd field by looking if the raster started in the middle of the first or last non-sync raster. However, if the syncs are 3 rasters each as in my new theory, that means the rasters before and after are simply blanked (but otherwise normal) meaning we can't see if VIC is generating a half raster (and if so where).
Wish I had an o'scope.
I'm curious if anyone has tried this with PAL?
Also, I want to tell mysticshadows that the vic-ii document he referenced, although not having the correct information about the end of the v-sync/v-blank, does have the correct information about the start of v-sync/v-blank (at least for the NTSC). So I think it's likely that the start is also correct for PAL.
I've made a figure to illistrate how I think the interlace method works.
(http://landover.no-ip.com/images/vic2emethodeven.gif)
Here the 'cut' begins on raster 14 and ends in the middle of raster 17, the first v-sync raster. Note for NTSC there are 3 pre-equalizing rasters. I think for PAL there are only 2 pre-equalizing rasters. Also for NTSC there is 1 v-blank before the equalizing rasters.
Putting this altogether, it might work for PAL if the 'cut' occurs on line 300. This should 'cut' the half of the v-blank line, then the two pre-sync lines, plus half of the first v-sync line. In other words, in may work if the PAL VIC-IIe produces v-sync on raster 303.
The problem with my demo, is it only supports rasters 0-255 (not to mention it is expecting 65 cycles/line instead of PAL's 63). I plan on making a new NTSC/PAL compatible version, but was interested in some feedback from any PAL folks who may have tried it.
I'm glad it was useful in some way :-).
I can't wait to see what you'll be doing with all this :-)