NTSC interlace detail info needed

[groepaz]

Hoy!

So, DQH recently started adding support for proper interlaced rendering (right now works with C128 VDC only) - so i'd like to add support for this in xvic aswell. Unfortunately i couldnt find any detail info on how it actually works, perhaps one of you (tokra?) can shed some light on it

first, is it correct that the general idea is to set bit 7 in $9000 and then the VIC shows alternating frames with "half a line" offset every other frame. it doesnt handle any page flipping or whatever else by itself. and the only way to find out what field is (has been) displayed is by checking the presence of rasterline 263 ($83 in the register)?

then, i need to know precisely how many cycles are spent in the last rasterline of odd and even frames - this is the key to get timing right.

It would be really nice if someone who owns a NTSC vic20 could knock up some simple test programs that checks those things, so we can make it work in VICE

I tried using "retina display" and actually managed to make it show something by simple alternating between 262 and 263 lines in odd/even fields, however, although the display is stable (the raster splits do not crawl over the picture, so the overall amount of cycles is spot on) they are not at the right places, which makes me believe there isnt actually a full line 262 and/or 263 - which actually makes sense.

here is my current hack, very ugly (and also makes bit7 work on PAL, it will likely totally misbehave in that case) is here: http://dpaste.com/8SLXWJC6B - i couldnt work it out yet by trial and error, so its probably not quite right (this will not actually enable correct rendering yet, right now we only need to solve the timing part, then we can hook up the rendering to show the correct picture)

Speak up please!

[tokra]

[...] support for proper interlaced rendering[...]couldnt find any detail info on how it actually works, perhaps one of you (tokra?) can shed some light on it

Actually, I'm just an "experimental" programmer. I try what works and stick with it Not really sure of the inner workings of the VIC, but...

first, is it correct that the general idea is to set bit 7 in $9000 and then the VIC shows alternating frames with "half a line" offset every other frame. it doesnt handle any page flipping or whatever else by itself. and the only way to find out what field is (has been) displayed is by checking the presence of rasterline 263 ($83 in the register)?

... essentially this should be it. Also, please see this thread from 2015, where we found out that rasterline 0 starts 33 cycles late:

http://sleepingelephant.com/~sleeping/i ... =15#p80722

You even made a fix in VICE back then, this may interfere with your current hack:

https://sourceforge.net/p/vice-emu/code/29805/

Regarding interlace my finding are already documented in the VICE-testrepo:

https://sourceforge.net/p/vice-emu/code ... vic_line0/

This is the most interesting part:
"For fun I switched the interlace-bit on with POKE36864,133 before starting this
test and the results are the same for values 1 to 131 (one extra value in inter-
lace). However for value 0 one half-frame starts at position 33 and the other at
position 0 as well.

So it looks like the reporting to $9004 is delayed for 33 cycles when a new
frame starts and not when a half-frame starts. I could not find any other
irregularities regarding reporting of $9004 just the one for value 0."

I can test anything else you throw at me on a real NTSC-machine to confirm/disprove any theories.

[groepaz]

gotta re-read that thread, i vaguely remember it

it would be cool if you could provide screenshots from that test program when interlace is enabled (perhaps make a video somehow and then grab an odd and even frame from that?)

[groepaz]

Another thing: it would really help if you could add a dejitter routine to that testprogram - then i can transform it into a testprogram that can work with the automatic testbench.

Any other ideas what kind of behaviour could be confirmed using test programs would be nice too... eg a test that measures the exact number of available cycles per (half)frame would probably help too

[Mike]

tokra and I discussed that in a short call - I'll write a routine that 'scans' the presence/number of values in $9004 in the two rasters before and after each frame change, for 256 cycles in total and for both even->odd and odd->even frame changes.

The main part will look roughly like this (each LDA/STA pair needs 8 cycles):

Code: Select all

LDA $9004:STA $xx00:LDA $9004:STA $xx08:LDA $9004:STA $xx10:[...]:LDA $9004:STA $xxF8

(wait for next same-type frame change and delay 1 additional cycle)

LDA $9004:STA $xx01:LDA $9004:STA $xx09:LDA $9004:STA $xx11:[...]:LDA $9004:STA $xxF9

(and so on, up to:)

LDA $9004:STA $xx07:LDA $9004:STA $xx0F:LDA $9004:STA $xx17:[...]:LDA $9004:STA $xxFF

tokra has the NTSC we need to run this, so we're set.

This is the plan, and now I am off for a good walk on this nice Sunday!

Michael

[tlr]

tokra and I discussed that in a short call - I'll write a routine that 'scans' the presence/number of values in $9004 in the two rasters before and after each frame change, for 256 cycles in total and for both even->odd and odd->even frame changes.

For what it's worth there are some tests I wrote in that spirit here, although nothing that tests in interlace mode:
https://sourceforge.net/p/vice-emu/code ... lit-tests/

[Mike]

Hi groepaz and tlr,

it's more complicated than we thought. Tokra ran my scanner program, and the value $83 in $9004 actually appears in *both* types of (half-)frames, albeit for a different number of cycles. More info to follow ...

Greetings,

Michael

[groepaz]

Any news?

[Mike]

Any news?

Torsten and I are working on it. Intermediary results are as follows:

• Non-interlaced fields start with a partial raster 0 ($9003 = $2E, $9004 = $00) of 32 cycles. Rasters 1 ($9003 = $AE, $9004 = $00) up to 260 ($9003 = $2E, $9004 = $82) are complete with 65 cycles each. The fields end with a partial raster 261 ($9003 = $AE, $9004 = $82) of 33 cycles.

Interlace outputs two types of fields:

• Type 1 starts with a partial raster 0 ($9003 = $2E, $9004 = $00) of 32 cycles. Rasters 1 ($9003 = $AE, $9004 = $00) up to 262 ($9003 = $2E, $9004 = $83) are complete with 65 cycles each.
• Type 2 starts with a complete raster 0 ($9003 = $2E, $9004 = $00) up to complete raster 261 ($9003 = $AE, $9004 = $82) with 65 cycles each. It ends with a partial raster 262 ($9003 = $2E, $9004 = $83) of 33 cycles.

On our TODO list:

• The horizontal and vertical timing of $9004 with regard to stores into $900F, and whether that is the same for both fields: if one commences the store cycle of a STA $900F exactly where a LDA $9004 load cycle would sense "cycle 0" of a new (double-)raster, where does the colour change end up on screen?
• The assignment of "Type 1" or "Type 2" to "even" or "odd" and which one of them is the "top" raster is also not yet settled and is under investigation.
• Where does VIC sense/latch the interlace bit? How exactly is the transition between non-interlaced and interlaced done?

Greetings,

Michael

[groepaz]

interesting! i'll wait some more then until you collected all that info

[Mike]

Here is now a set of two example/test programs that check the timing and the field order in the interlace mode of the NTSC VIC-20 VIC-I chip (download). Both 'test7a.prg' and 'test8a.prg' require a +8K RAM expansion. The archive also contains higher resolution photos of the screenshots below.

Thanks go to tokra for testing the programs on his NTSC VIC-20 and providing photos from the output on a LCD TV.


This is sample output from 'test7a.prg':



Immediately after RUN, the black frame is empty. The green rectangle will appear after a key press. It consists only of changes of the $900F background colour to green for 4 cycles, over 32 raster lines. The black frame takes the expected delay of the colour change of 1 hires pixel into account, however one can see a slight mismatch to the expected result: Chroma seems to be shifted slightly (less than 1 pixel!) to the left, which gives a noticable small, white(?) gap between the right side of the rectangle and the black frame. This surely needs to be investigated further, but in another context.

Result: For the shared full raster lines 1..260, the timing of screen scan/effect of changes to colour registers with respect to changes of $9003/$9004 is the same for interlaced operation mode and non-interlace mode, regardless which type of field!


This is sample output from 'test8a.prg':



The program shows a display with a 160x384i graphics mode. The two fields are placed at $1000..$17FF (top field) and $1800..$1FFF (bottom field) and are supposed to show a smooth circle with accompanying text. The code continually polls a VSync before switching the field data (with writes to $9005) and while doing so, checks the length of the last line 262 in each field:

Code: Select all

.Count262
 LDX #&00
 LDY #&81
.Count262_00
 CPY &9004
 BNE Count262_00
 INY
 INY
.Count262_01
 CPY &9004
 BNE Count262_01
.Count262_02
 INX
 CPY &9004
 BEQ Count262_02
 CPX #&06
 RTS

(Note this is copied straight from the source and uses "&" to denote hexadecimal constants!)

When this subroutine exits with C=0, it has sensed a short line 262. When it exits with C=1, it has sensed a long line 262.

Result: The top field follows a short line 262 (C=0), the bottom field follows a long line 262 (C=1)!


The exact switchover behaviour between non-interlaced and interlaced operation mode is still on the TODO list and will be probed next. But the current info is already sufficient for the interested coder to implement working interlace displays on the NTSC VIC-20 in a robust way.

Greetings,

Michael

[groepaz]

MMMh while those two tests are fine for demonstrating it all works - they are not really useful to fix the emulation didnt you write code that measures the respective timing?

[Mike]

Yes, the code to measure the timing (still) is there and functional, but the very first tests I wrote used an assumption - line 262 (counted from 0) present in only one type of interlaced frame - that has proven invalid. The traces were still useful as they showed the behaviour of the critical lines 260..262 and 0..2 for both types of fields (by including a delay of a field to measure the transition at the supposedly missing line 262) *and* I was lucky that the transition nolace->interlace enforces a certain type of field, so the results were deterministic. But hard to interpret.

I am currently working on a refined set of tests that take the current findings into account.

In the meantime, the results of 10th July are still valid as posted here. The new set of tests will include checks for these results.

[groepaz]

I'll have to wait then Tried some quick hacks last night but only made everything break apart - the code isnt really able to handle with incomplete lines unfortunately. 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). At this point i am also super confused about the total number of scanlines (and thus cycles per frame), which apparently is wrong (one line less than there should be). However the raster effects in various NTSC games are stable, which again implies its correct. *shrug*

[Mike]

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).

I'm working on that.

At this point i am also super confused about the total number of scanlines (and thus cycles per frame), which apparently is wrong (one line less than there should be).

To rephrase my post of 10th July:

• no-laced fields: line 0 with 32 cycles, lines 1..260 with 65 cycles, line 261 with 33 cycles. total number: 32+260x65+33 = 261x65 cycles
• interlaced top field [1]: line 0 with 32 cycles, lines 1..262 with 65 cycles
• interlaced bottom field [2]: lines 0..261 with 65 cycles, line 262 with 33 cycles
• top + bottom field combined cycle count: 32+262x65 + 262x65+33 = 525x65 cycles

So, in both cases a multiple of 65 cycles, either for each no-laced field, or for top and bottom field combined in an interlaced frame. The suite of tests I'll post next will specifically check/confirm these findings.


[1] the top field follows the short line 262 of the bottom field as established by my Count262 routine in 'test8a.prg'
[2] likewise, the bottom field follows the long line 262 of the top field