Previous | Next
| From: TLC (all posts)
Date: 1998-05-13
Subject: Our thing is working!!!
|
Holly!
Yep, Crown your few words about the CCIR doc made me play with my old interlace routine. The result, I seem to have a stable one (interlace on all TV's I checked, and no color problems).
The source is about 10K long (it contains a lot of other features). Guys,
should I post it to the list or better not? Anyway, it can be compiled on PC with TASM (I mean, the Table Driven ASM by Speech Technologies).
Either case, I'll put the source to the Falcon site tomorrow, with some converted images which were converted much earlier (...better not play with the conv for now, I have no time for this buggy stuff).
I'll reply with the complete location tomorrow.
Well, you should also test it on a lot of displays. All the code was done on a regular Plus/4 with a CBM 1802 monitor but with no scope. So I still won't claim if it is free of bugs.
In short, my old routine was almost correct (I mean, the one which generated laced screen with bad colors).
I don't know if the method fully matches the standard. I still don't see the point of the missing line (since I haven't found that). I knew, interlace goes somewhere in the vertical retrace. I also knew,
something must happen instead of simple longer or shorter frames,
just because of the VR signal I checked adjusting the screen position.
What I did in my routine, I use two different frames. The first is a usual one, I don't play with the regs. The second is modified.
When the beam reaches the start of VR, I delay the vertical raster position by half a line. I wait some lines, just to the end of the vertical blank signal area. Here I again, make it wait for a halfline.
This just gives right interlaced screen (this was the method of my earlier routine). But since the frame became larger by one line,
the colors go off. ...It is not obvious, why must they go off but I suppose the reason must be in the PAL standard, or rather, how Commodore achieved compatibility with this standard. Or I don't know. I also suppose that it must have something to do with the behaviour of the VIC-20
6561. In general, the colors go wrong if the beam is moved by odd number of lines. (You don't even have to draw that frame by this odd linenumber, it's enough if you, for example, step $ff1d forward by one line, and one line later you step it back. The lines, where you did it will change their colors, though their color code is still the same.
I used this trick in one of my first demoparts, ...Lavina may know it,
it was in Gotu Mega 1.)
What I did today, I inserted code which steps $ff1d backward by one line right after making the first half line delay. The reason, I knew from earlier that doing such things in this area doesn't really affect the next frame, but then it will compensate the one line difference of the two halfline tricks. After few hours of work, it seems to run correctly.
Interlace seems to be generated by the different phase of the blank signal.
My tricks, I realise, made the blank signal start later by half a line,
and then, the VR signal ends in the same position but one line later in overall than it was 'normal'.
(I still suppose that I must do that measurement with the scope.)
O.K., I'll be back tomorrow with the stuffs on the FTP, if it'd be good I'll also send the code to the list.
Now some replies in few words.
[Vic-20 thing]
Hmmm, I won't suppose anybody to believe. TIY.
> Actually this list was born, for sharing these infos with the emulator
> writers, so they could make better ones. :)
Whew? :-)
> If you have these docs
> and you can share with us that would be welcomed on this list!
Like you did, I also have these on paper. O.K. I'll translate to text soon.
> I'm sure you know about the unconnected space
> feature. If the CPU or the TED reads from an unconnected address space
> (for example from a non existent cartdrige, or the area at $fe00-$feff
> if there is no 1551 on a C16) then the read data will be the same which
> was read or written on the previous cycle.
Yes, I did a lot of fiddling with this matter.
Also, I don't know if you tried the same in twiee clock mode but it shows an interesting behaviour. Since normally, this area is border,
when you open the border, you'll see the background color with some garbage but the proc will still run at the faster clock speed.
But the garbage helps to point out that TED is still in read in all the cycles. ...You would ask, why the memory fetches of the processor don't get fucked up if the TED is also addressing the memory, it's impossible. ...Here's Marko's favourite trick: since TED is addressing
$FFFF, and since TED is an NMOS device, it's addresses will be wire AND-ed with the processor's address lines. The result is, the address requested by the processor. And speaking of the garbage, eh, well... you can still see every second memory fetch of the processor shown by the TED.
> Do someone knows what is this Equalize thing?
These are the few black lines right after the VR signal. Maybe, it's task is to help the TV to get 100% synchronised (horizontally) before the screen area starts.
> Also, there are some tolerances, and if it is in then it's ok.
Well, it have been my luck. Since 57 can't be divided by 2, my routine can't delay half a line exactly. This is indeed, can be seen if you check the VR signal generated by the routine. ...But it seems to work.
(Also, did you notice that whether bit 1 of $ff1e is alive while reading,
it seems to be unconnected in the write register. The beam can't be moved by half a character)
Levente
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
