Mail Archive - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Previous | Next

From: Crown (all posts)
Date: 1998-05-13
Subject: Interlace

Hi there,

Levente:
>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).
Cool, I got that info from a 3DO tech support guy some years ago when I was doing some development on 3DO. (They always answered something totally different, I guess they never understood what I was asking. :)
Good, that I kept those faxes.
I do have the same datas for NTSC, maybe someone will fix your interlace routine to run on NTSC also. So here we go:
An NTSC line is 63.555 usec, H-blank time is 10.9 +/- 0.2 usec and V-blank time is 19 to 21 times of the line time + a horizontal blank time.

>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 sounds like you make this frame 1 line longer, so it takes the time of 313 lines. Added together with the normal frame gives 625 lines. I guess here is your missing line.

>(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)
Yes, both bit 0 and bit 1 is ignored and not changed when writing. When reading, bit 0 is always 0.

Unconnected space and border off stuff:
>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,
Sure did that.

>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 Yes, I've also read his docs... :)
I think, that in a CPU cycle the TED sets it's address bus to
$ffff, while in a TED cycle the CPU does this. In the above mentioned example the TED sets its address bus to $ffff as the address generator component of the TED was turned off at line $CC, so this cycles are CPU cycles, but the display generator component wasn't turned off,
because of the 25/24 line switching trick, so it displays what are on the data bus. From this we can say, that in a normal CPU cycle the TED also gets the data bus content, but simply doesn't care about it,
and also the CPU gets it on a TED cycle, but also doesn't do anything with it. (Hmmm I just thinking here about those illegal instructions for which no one found reliable explanations, could it be that this affects those? Probably not, but it's worth to check.)

>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.
Yes, but in slow mode both the CPU and the TED sets its output to $ffff,
and if this is an unconnected address, then the data bus will stay in the same state as in the previous cycle, so you can see every CPU cycle!

If you are reading an unconnected space by the CPU, and the previous cycle was a TED cycle, you will get the data read by the TED. Actually I used this method to verify the positions of the F cycles.

Tibor Biczo / Crown of GOTU