Previous | Next
| From: TLC (all posts)
Date: 1998-05-11
Subject: Re: TED timing, Interlace
|
Hi guys!
Marko: I also played a lot with the Vic-20's videochip. I came to conclusion that they did something very weird when they designed the videochip, at least, the PAL version (the 6561). The chip generates much different colors on even and on odd lines, for the same color code.
I mean, if you set a raster routine which generates a 'zebra' grid in the background color (every second line is black), you will see different color on the screen if the 'colorized' lines are even or odd.
I mentioned this, because I suppose, the 'color interlace' effect which is utilized regularly in C-64 FLI demos was originally invented by Commodore. The NTSC videochip which you sent me recently (6560-101)
seems to switch the mentioned 'even' and 'odd' roles frame by frame,
resulting in a bit flashy but constant colors of the screen. While,
checking the PAL Vic-20's screen, you usually see a more or less sensible bar pattern and jerky characters (because of the different colors and intensities of every second line).
Crown:
Yes, I sent you a letter some months ago, and I received your letter regarding the corrupted mail, and I also replied but this one seemed like not to reach your mailbox. Neither I have the message text yet,
I remember I just wanted to say a Welcome to ya back in the Plus/4
World and also asked if you have a webpage or your programs are available somewhere on the Net. ...I liked your Iron Maiden demo :-), I guess once I even played a lot with it's music and a wave converter :-) (I had no C64 until the end of '92 to watch the original C64 demo).
I still use USA.NET but only for mailforward. The reason is, I don't wanna change my e-mail address for a while, even if I change ISP.
Some years ago I also made such a TED timing diag, all with the usual stuff of single and twiee clock, the proc's and the TED's cycles,
memory refresh, transparent DMA, all how it's related to $ff1e and so on. Well, though, it wasn't really considered worthy by anybody. I wrote a bit smaller TED doc which was published in the Commodore Hacking mag
(after a lot of, yep, bitching, O.K. I don't care about it but this article can be found somewhere on WWW.FUNET.FI too) describing regs,
modes also with $ff1e's behaviour.
I haven't managed to open the sideborder (O.K. I did but I've never been able to make TED fetch character pointer data for the new places, or,
color memory if bitplane mode was active). I saw some code from Larry who did it some time ago (I guess he never released it in a demo).
But well, I managed to write some interlace routines, even in FLI mode (...it was also some years ago, Marko, you've seen results). First I also delayed the vertical retrace point, but I also noticed that buggy interlace effect. Later I tried to copy a normal TV's synch signal (if you have a regular TV signal, you can be sure that it is interlaced).
This became never 100% correct, but I have two routines which work quite O.K.
Since I became owner of an Amiga, well... an NTSC Vic-20 too, now I have quite easier access to a real laced source. I also have a friend having a scope, so, whether you'll succeed experimenting this interlace thing or not, I'll get the NTSC Vic-20 and the Plus/4 to the scope and see, what happens. ...Well, first I must finish my master's thesis.
Also, I made a converter routine for the PC box which can convert some PC-256 color gfx to Plus/4, even for this interlace mode. This was my master's thesis for the programming course I finished in '93.
BTW, regarding the $ff1e thing, I thought you wrote cycle exact timing much earlier. I saw one of your demos (hmmm, maybe even from '90)
containing a splitted raster scroll which I guess just needed this exact timing.
> Lion, it looks ok, so I would say it's 100% ok.
> I have only one addition, how this relates to the
> horizontal dot counter register ($ff1e). So
> in cycle 1, $ff1e contains $c4, in cycle 2 it contains $c6.
> It increments by 2 at every cycle till it reaches $e2, this happens
> in cycle 16, in cycle 17 it is set to $0, then continues incrementing
> by 2, and in cycle 114 it is $c2.
Yes, mentioning that not all of these phases can be detected because the proc can't always read the regs (ie. in single clock mode, or in refresh cycles the proc can't reach the bus in the first half clock phase).
Regarding the other post, your TED-diag which was sent by Lion, yes, it seems to match my measurements. The only difference that I numbered the cycles from 0 to 56 and splitted them to two phases (but the result is the same). Also, maybe it was misspelled but there are 109 cycles on a border, 'fast mode' (= twiee clock enabled) line instead of 114 'cos the TED does it's memory refresh, 5 cycles on every line whether you select either clockmode (this makes 5 less cycles).
Also, the cycles assigned ' - ' ( Empty ) contain TED reads from the address $FFFF (you can experiment with it by removing the vertical border by the C-64 like $ff06= 03, 0b trick and checking the resulting pattern on the screen). Well, it doesn't seem to be much serious anyway.
It would be sensible to measure which memory cells are addressed during memory refresh cycles (...maybe, Marko did some experiments on this recently, at least on the VIC-II).
> Interlace:
> I've played a little, but with not much results yet. What I could
> achieve, that in the upper area of the screen, it was true interlace,
> but in the lower areas of the screen it was again normal. I tried
> to delay the end of the vertical sync signal, by 1 line, and because
> of this delay-timed sync the raster line was moved, but the TV detects
> this, and tries to compensate, so at the time the electron beam reached
> the lower area it succeded. I haven't given up yet, so will check this
> further....
No, the point is: to present a regular interlaced v-retrace signal. I've read some docs about this. Other words, you can remember: a real laced screen contains 625 lines (in Europe). Since Plus/4 generates 312, if we double it somewhere must be a point to find the missing line.
I supposed if one frame should be a half line shorter, and the another by one and a half line longer than a normal half frame. But I haven't succeed; once, my routine generated a real laced screen but it fucked up the colors on a color TV-set (note, you must also take care about the color subcarrier signal), and another worked well on that TV but refused to do interlace on an other one.
(You (or anybody) can have them and some gfx if you'd like to. Just write; I can mail them, or put some of them up to the falcon.pmmf.hu ftp.)
But I guess, this effect can be made 100% correct only, if at all, using a scope and measuring the resulting V-retrace signal instead of playing with an appropriate TV (...else evil knows if the resulting laced signal will work well on another displays). You can also try it if you have a scope.
Levente
Ps. Lion: Yes, it's possible to do on Plus/4 :-). The TED is some more flexible than the good old VIC-II.
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
