Denial

groepaz wrote:I'll have to wait then

Here we go: interlace_2021-08-16.zip

It would be super useful to also have the same tests with measuring for the regular non interlaced ntsc mode - i should try to fix this first (properly, not using the hack i did before).

Please check against "~/results/nolace.txt" - my somewhat older WinVICE 3.1 r34289 reports 98 cycles in line 260 and omits line 261.

Real hardware gives a different result, 65 cycles in line 260 and 33 cycles in line 261, in agreement with what I reported in my earlier posts here.

Note: the first and last lines of the result files start resp. end their scan somewhere in the middle of a raster (thus disregard their counts!), but still at a cycle exact synced-to position!

Greetings,

Michael

great! i have (mostly) fixed the timing now, please check https://github.com/VICE-Team/svn-mirror/releases (build will appear in an hour or so)

there are still some problems.... first, "retina display" seems to not work correctly still. i have no idea why. is it mixing up odd/even frames? or is the timing one rasterline off? another test might be in order

it would also be really cool if you could make a PAL- and (NTSC) non-interlace version of the test7a program - that allows to check the timing real quick, and there is some stuff in the code that needs to be made more generic regarding the raster timing, right now interlaced is too much of a special case hack

groepaz wrote: ↑Tue Aug 17, 2021 8:39 am there are still some problems.... first, "retina display" seems to not work correctly still. i have no idea why. is it mixing up odd/even frames? or is the timing one rasterline off? another test might be in order

I just checked this with r40518.

When switchting from non-interlace-mode to interlace-mode the VIC will finish the frame it is currently in as the top-field of the interlace-mode and consider the first "full" interlace-field that follows to be the bottom-field. I'm sure Mike can explain better and provide the test-program for this. We actually tested this.

When I originally programmed "Retina Display" I only really got it working by observation. However Mike's tests he did with me confirm the switching behaviour as described. For fun I started Retina Display with the interlace-bit already set and then I got the same faulty results 50% of the time you now see in r40518.

So, it is important to keep the field-order correct when switching to interlace. The one in VICE now seem to be exactly the wrong way around.

I also noticed VICE still uses full height rasters, but actually the rasterlines in interlace-mode should only be half as high each to provide the higher resolution.

tokra wrote:I'm sure Mike can explain better and provide the test-program for this. We actually tested this.

I am working on a version of those tests that export the data as file, so we don't need to compare screenshots.

The rendering being wrong (as in: not doubling the resolution) is expected right now, btw - right now i have only fixed the timing. Rendering comes next

try r40548 now - field order is fixed and its rendering actual interlace

whats missing now is some detail info on how the interlace mode switching works exactly... is the register bit latched in a certain cycle, or can it be changed any time... etc

groepaz wrote:whats missing now is some detail info on how the interlace mode switching works exactly... is the register bit latched in a certain cycle, or can it be changed any time... etc

There is already a working first set of tests. However they again indicated the behaviour of VIC-I is somewhat more complex than tokra and I thought: switching from non-interlaced to interlaced mostly shows expected results, but the video chip is slightly upset, when the interlace bit is changed back to non-interlaced, while VIC-I is generating those lines that do not exist in the non-interlaced field.

As I wrote, I am currently working on a version of those tests that save the relevant data to a file instead of showing it on screen, and they will also record a wider range of possible latch positions.

but the video chip is slightly upset, when the interlace bit is changed back to non-interlaced, while VIC-I is generating those lines that do not exist in the non-interlaced field.

oh, yeah i can see that :=)

groepaz wrote: ↑Sat Aug 21, 2021 7:02 am try r40548 now - field order is fixed and its rendering actual interlace

That looks really good! I still like the "CAT"-picture of "Retina Display Color" the best.

I noticed that when making a screenshot ("Save media file") it seems to use only one of the fields.

yeah, screenshot is still an unsolved problem (and likely will be for a while)

The interlace flag essentially adjust the point at which the vertical counter is reset. If interlace is off it resets somewhere on line 261 to generate 261 lines/'field' and if it is on it resets somewhere on line 262 to generate 262.5 lines/field.
In fact you can trick the NTSC VIC so that the reset is never triggered by turning on interlace, and then turning it off when $9004 reaches 131 (262/2). Then turn interlace back on later. (Similar to opening the borders on a C64.) this will also generate video output consisting of 512 lines per frame, so it will also confuse most (all?) monitors.

interesting... it would be nice to have a testprogram to verify the exact cycles where this happens

NTSC has a total of 525 lines. I interlace mode you have 262.5 raster lines. If it takes 65 cycles to draw a complete raster line, then you would have 32.5 cycles to draw that last half-line.

DrVeryEvil wrote:NTSC has a total of 525 lines. I interlace mode you have 262.5 raster lines. If it takes 65 cycles to draw a complete raster line, then you would have 32.5 cycles to draw that last half-line.

And that is supposed to mean exactly what ...?

There's a bit about NTSC interlaced mode in my notes at HTTP://www.brawn.org/VIC-20/Video

However, there are some bits in there that don't make sense to me yet.

When in interlaced mode the odd and even frames each have about the same number of lines as a non-interlaced frame, which is not how interlaced video is supposed to work. I measured that an interlaced field has 1.5 lines more than a non-interlaced frame.

By convention, the field that starts with a full line is the odd field, its last line will be a half-line. The next field is the even field and will start with a half-line.