VPOSW LOF bit

[mark_k]

How does the VPOSW LOF bit work? I know that when the BPLCON0 LACE bit is set, it toggles on/off for successive frames/fields. But what about setting the bit manually, when using a non-interlaced display mode?

I did some testing with WinUAE. I booted to a non-interlaced Workbench and dumped the system copperlist. There were no writes to VPOSW, so I thought that if I write VPOSW once, the LOF bit state would remain at 0 or 1 (depending on the value written).

A single write to VPOSW with LOF=1 seemingly does nothing. Busy-looping setting LOF=1 also seems to do nothing.

A single write to VPOSW with LOF=0 causes some log output:
NTSC mode V=53.6424Hz H=21760.0920Hz (163x405+0) IDX=11 (NTSC) D=0 RTG=0/0
NTSC mode V=53.8143Hz H=21760.0920Hz (163x405+1) IDX=11 (NTSC) D=0 RTG=0/0
(that example done while using a non-interlaced HighGfx mode Workbench)

Looping setting LOF=0 causes this log output:
NTSC mode V=53.6424Hz H=21760.0920Hz (163x405+0) IDX=11 (NTSC) D=0 RTG=0/0
NTSC mode V=53.6424Hz H=21760.0920Hz (163x405+0) IDX=11 (NTSC) D=0 RTG=0/0
NTSC mode loflace V=53.6424Hz H=21760.0920Hz (163x405+0) IDX=11 (NTSC) D=0 RTG=0/0

and the output image becomes one scanline shorter. (And from the "loflace" text, WinUAE thinks the video signal is interlaced.)


Next I tested using an interlaced Workbench:
- Looping setting LOF=1 causes one field to be displayed in both odd and even output scanlines. (So the opposite field is never shown)
- Looping setting LOF=0 does the same for the opposite field.
That happens even when WinUAE's interlaced line mode is set to "double, fields+"...


The effect on real hardware must be noticeably different. Perhaps running one of the test programs will show similar output to WinUAE's "single" interlaced line mode: output image non-interlaced, frames alternating between the odd and even scanlines of WB screen?

[Toni Wilen]

My crystal ball says you use KS 3.1. It resets LOF in vblank interrupt. (EDIT: Which actually broke some games that partially take over the system and tries to enable interlace or switch it off)

[mark_k]

You're right.

I did some more testing (with Kickstart 2.05 this time). Running the loop to set (or clear) the LOF bit causes the display to become non-interlaced, with only odd (or only even) field lines showing. Does that match real hardware? I guess it could, if the system vertical blank interrupt routine reads VPOSR and sets the copperlist pointer based on that.

[Toni Wilen]

Small correction to my previous post: graphics.library vblank routine only sets LOF bit if current mode (by checking its internal bplcon0 mirror register) is not interlace and LOF is not already set.

I guess it is workaround for interlace to non-lace mode switch that could leave field mode to short fields if interlace was switched off during short field.

[Seoman]

Then, if I'm using KS 3.1, ¿how can I set up an interlaced screen if I can't use LOF to check odd and even scanlines?.

[Toni Wilen]

Originally Posted by Seoman

Then, if I'm using KS 3.1, ¿how can I set up an interlaced screen if I can't use LOF to check odd and even scanlines?.

a) Let OS do it. Don't try to do any tricks, don't hit the hardware.
b) Properly take over the system and hit the hardware normally.

If you don't want to take over the system but still want to directly use (display) hardware:

c) Use OS routines to open interlaced screen first. This way OS knows mode really is interlaced and it does not try to fix it.

[Seoman]

Thanks Toni.

Can anyone give me an example in assembler to set up an interlaced screen in a OS friendly way?

[Blueberry]

So THIS is why the sound in my demos sometimes crackles!

I always thought non-interlaced frames were always long. Based on this assumption, I write 573 samples each frame to my circular sound buffer and play it with period 124. 573*124 = 71052 is so close to a long frame, 227*313 = 71051, as to make no difference in practice, and when the frames are indeed long, this works perfectly. However, if the frames are short (which they can be for instance if the demo is started from an interlaced screenmode), this of course breaks horribly...

[Mrs Beanbag]

i did wonder if it would be possible to achieve sub-pixel vertical scrolling by writing to this bit

[hooverphonique]

Originally Posted by Mrs Beanbag

i did wonder if it would be possible to achieve sub-pixel vertical scrolling by writing to this bit

yes, you can.. I've done that in the past.. works a treat and looks really nice.. at least on a 15KHz CRT

edit: I think it was in the end scroller of this one I used it: http://janeway.exotica.org.uk/release.php?id=185

[Toni Wilen]

Can anyone give me an example in assembler to set up an interlaced screen in a OS friendly way?

I don't have any good enough examples, sorry. But normal 1.x NewScreen structure should work fine. Perhaps 3.0+ PAL_MONITOR or NTSC_MONITOR monitor tag is probably also good idea to force RTG off if in use.

edit: I think it was in the end scroller of this one I used it

No interlace or vposw writes in that demo.

It still would be normal interlace mode, no need for manual VPOSW writes.

It is display device that decides vertical start position and it is decided during early part of vertical blanking. Modifying VPOSW during visible portition of display does nothing.

[hooverphonique]

Originally Posted by Toni Wilen

No interlace or vposw writes in that demo.

It still would be normal interlace mode, no need for manual VPOSW writes.

I must've remembered incorrectly then.. It is the correct intro, however..

you are right about the interlace part, of course - it's just interlace mode, but using the same bitplane pointers for both fields, and then scrolling the buffer one line every other field (i.e. no manual writes to VPOSW).

[mark_k]

Originally Posted by Seoman

Can anyone give me an example in assembler to set up an interlaced screen in a OS friendly way?

If you don't want to use Intuition to do it but go directly to graphics.library, there's a good example in the RKM: Libraries. I think that's neater if you intend to kill the system anyway.

Quote from that:
** The following example creates a View consisting of one ViewPort set
** to an NTSC, high-resolution, interlaced display mode of nominal
** dimensions. This example shows both the old 1.3 way of setting up
** the ViewPort and the new method used in Release 2.