Interlace mode: More line, more dma slots?

[sandruzzo]

With interlaced mode, do we have more dma slots cos more line?

[chb]

No. The number of lines per frame is the same.

[Toni Wilen]

Actually you one or half (depending on how you want to count them) lines less because interlace is alternating 313 and 312 line fields. Normal non-laced is 313 lines.

[dodke]

Can you actually enable bitplanes for one more scanline during the long frame?)

Btw off topic but does (win)uae support flickering the scanline filter so that current frame is bright and previous frame is dark?

[Toni Wilen]

Originally Posted by dodke

Can you actually enable bitplanes for one more scanline during the long frame?)

No (except A1000), bitplanes and sprites are disabled during last line. But it is still normally available for other DMA channels and the CPU.

Btw off topic but does (win)uae support flickering the scanline filter so that current frame is bright and previous frame is dark?

Display panel "Fields+" mode should do it.

[pandy71]

Originally Posted by Toni Wilen

Normal non-laced is 313 lines.

Isn't normal can be 312 for short OR 313 for long?

[ross]

Originally Posted by dodke

Can you actually enable bitplanes for one more scanline during the long frame?)

Hi dodke, just curious..
Why do you want to see a one more scanline?

(actually you can write to VHPOSW to increase/decrease lines, but so you also change video frequency )

[if I'm not wrong Dyna Blaster do this to fake a quasi-NTSC mode on PAL Amiga]

[pandy71]

Originally Posted by ross

(actually you can write to VHPOSW to increase/decrease lines, but so you also change video frequency )

Only vertical frequency - horizontal and pixel clock stays unaltered.

[ross]

Originally Posted by pandy71

Only vertical frequency - horizontal and pixel clock stays unaltered.

of course.

Has anyone ever tried to change the horizontal frequency?

EDIT: now that comes to mind, and if I remember correctly, there is a demo that does it to make an effect with the copper!
(only a little change to x value to shift initial copper position)
But to not lost sync every other line reset the position.

[pandy71]

Originally Posted by ross

of course.

Has anyone ever tried to change the horizontal frequency?

EDIT: now that comes to mind, and if I remember correctly, there is a demo that does it to make an effect with the copper!
(only a little change to x value to shift initial copper position)
But to not lost sync every other line reset the position.

I've tried many years ago - it was fail (from strange effects on particular horizontal lines to complete hang on Amiga) - but my knowledge was very limited (no information about details of Amiga chipset, electronics, coding) also my test equipment was highly limited... only TV hooked by SCART to Amiga.
But it should be feasible only time tight Copper list required, perhaps CPU heavy usage too... anyway i observed horizontal frequency changes (HV transformer begin to sound very weird) - today no risk for LCD but those times i couldn't afford to broke TV.
Also curios about triggering with Copper STRHOR - $DFF03C - (this could trig Paula higher sampling rate) - tried but fail was obvious - whole system halted (tried with CPU - perhaps Copper in middle of line could do something better).

[Chrille]

Originally Posted by ross

Hi dodke, just curious..
Why do you want to see a one more scanline?

(actually you can write to VHPOSW to increase/decrease lines, but so you also change video frequency )

[if I'm not wrong Dyna Blaster do this to fake a quasi-NTSC mode on PAL Amiga]

IIRC Dyna Blasters writes #$0000 for 50 Hz Pal to BeamCon0 ($DFF1DC) Register
and #$0020 for 60 Hz (NTSC) to BeamCon0 Register and you could change it by pressing space (or some other key?) in the menu (???).

AFAIK this is only possible for all ECS+ Agnus Amigas e.g. A600, A500+, A1200 and also on some A500 with Kickstart 1.3. (those Agnus where you can address 1 MB Chip Ram, even when it is located at $C00000 for CPU and therefore not usable for the OS).

Originally Posted by ross

of course.

Has anyone ever tried to change the horizontal frequency?

EDIT: now that comes to mind, and if I remember correctly, there is a demo that does it to make an effect with the copper!
(only a little change to x value to shift initial copper position)
But to not lost sync every other line reset the position.

Yes, I've changed horizontal frequencies. If you change horizontal or vertical frequencies (other than vertical frequencies between 50 Hz to 60 Hz and horizontal 15,XX kHz) you need a multisync monitor (such as Amiga 1764, Amiga 1438, Mitsubishi EUM1491a, etc.). On other monitors it might be possible to slightly change the frequencies but not too much. I've tested this back in the days on my Phillips 88XX monitor. The monitor makes strange sounds if you change it too much

I've changed the frequencies in order to use all sprites on a resolution similar to productivty mode resolution (on AGA). The systems productivity mode is not appropriate for games with sprites at least if you want use all 8 sprites. Our first approach was to use a resolution with 640x512 Pixel x 64 Colors (or 640 x 256 x 64 Colors for non multisync monitors). We changed it later to 640x260 x 256 colors (so that we have to take no adjustments with 2 different resolutions) but we never finished the game and that's another story.

[ross]

Originally Posted by Chrille

IIRC Dyna Blasters writes #$0000 for 50 Hz Pal to BeamCon0 ($DFF1DC) Register
and #$0020 for 60 Hz (NTSC) to BeamCon0 Register and you could change it by pressing space (or some other key?) in the menu (???).

AFAIK this is only possible for all ECS+ Agnus Amigas e.g. A600, A500+, A1200 and also on some A500 with Kickstart 1.3. (those Agnus where you can address 1 MB Chip Ram, even when it is located at $C00000 for CPU and therefore not usable for the OS).

No, it is not managed this way, just checked to control also if my memory was broken
I extracted and commented the relevant code.

copperlist:
	...
	dc.l	$FFE1FFFE
	dc.l	$0401FFFE	; wait y==$104 position
	dc.l	$00960040	; 'pause' blitter (CPU can be hogged by BLTPRI)
	dc.l	$009C8010	; trigger copper IRQ
	dc.l	$01000000	; no bpls active
	dc.l	$FFFFFFFE	; CEND

irq3:	...
	MOVE.W	$dff01e,D1
	BTST	#4,D1		; copper IRQ?
	BEQ.B	.skip		; no, skip
	MOVE.L	$dff004,D0	; beam position
	AND.L	#$ff0000ff,D0	; isolate LOF+I and x position
	ADD.L	#$00013610,D0	; skip $136-$104=$32=50 lines
	MOVE.L	D0,$dff02a	; write new position to V(H)POSW
	MOVE.W	#$8040,$dff096	; restart blitter operation

.skip	BTST	#5,D1
	BEQ.B	.skip2
       ..VBI_handler

This also works on OCS as opposed to using BEANCON0 (which is obviously much more convenient).

Yes, I've changed horizontal frequencies. If you change horizontal or vertical frequencies (other than vertical frequencies between 50 Hz to 60 Hz and horizontal 15,XX kHz) you need a multisync monitor (such as Amiga 1764, Amiga 1438, Mitsubishi EUM1491a, etc.). On other monitors it might be possible to slightly change the frequencies but not too much. I've tested this back in the days on my Phillips 88XX monitor. The monitor makes strange sounds if you change it too much

I've changed the frequencies in order to use all sprites on a resolution similar to productivty mode resolution (on AGA). The systems productivity mode is not appropriate for games with sprites at least if you want use all 8 sprites. Our first approach was to use a resolution with 640x512 Pixel x 64 Colors (or 640 x 256 x 64 Colors for non multisync monitors). We changed it later to 640x260 x 256 colors (so that we have to take no adjustments with 2 different resolutions) but we never finished the game and that's another story.

Ok, this confirms that you did not use VPOSW which is a completely different story than BEANCON0 and related registers

[ross]

Originally Posted by ross

Has anyone ever tried to change the horizontal frequency?

EDIT: now that comes to mind, and if I remember correctly, there is a demo that does it to make an effect with the copper!
(only a little change to x value to shift initial copper position)
But to not lost sync every other line reset the position.

I quote myself :
[ Show youtube player ]

Fast forward to 11:45.
The copper effect on the upper part.

[Toni Wilen]

Yes, this topic is about almost undocumented way to change refresh rates that does not require ECS.

Originally Posted by pandy71

Isn't normal can be 312 for short OR 313 for long?

I meant "normal" as in the default (actually hardware default is short fields but all KS ROMs set it to long at boot) unless it was changed.

[pandy71]

Originally Posted by Toni Wilen

Yes, this topic is about almost undocumented way to change refresh rates that does not require ECS.

Changing vertical refresh rate is easy - CPU can nicely write to VHPOSW/VPOSW extending frame lenght (on real TV i've get progressive 625 lines at 25Hz - CRT flickered obviously but TV electronics worked correctly), i even extended frame beyond 625 lines on real CRT - flicker was worse but still OK, then i've made even more than this with my ancient analog oscilloscope going over 800 lines still stable refresh. Based on this i assume that OCS timing is very flexible and easily over 1000 lines should be doable at a cost of the reduced framerate - reduced framerate is not a problem from LCD perspective but it can be issue from human interface perspective (lower refresh rate will affect perceived latency and of course significantly reduced smoothness for or moving objects, mostly mouse pointer but not only). Limit is i think only counter length and chipset capabilities (OCS if i recall correctly has limit to 1024 lines and ECS/AGA extended this to 2048 lines) - but perhaps it can dealt in same way
Issue is horizontal timing as it is most demanding from time domain characteristic (lot of Amiga things seem to be hardwired to HSync).
As i wrote before - whenever vertical was easy to modify then horizontal was almost immediately penalty - or system hang, or loosing display, at best horizontal line distortions (it looks like only few lines in middle of screen disturbed for a while).

ECS/AGA is easy peasy when compared to OCS.

Originally Posted by Toni Wilen

I meant "normal" as in the default (actually hardware default is short fields but all KS ROMs set it to long at boot) unless it was changed.

This was my point - nothing is fixed - by altering single bit short or long field can be created as such Amiga display can be easily 624 or 625 or 626 lines and this is even more tricky when interlace is activated as field dominance can be easily altered during display and as such it may ruin deinterlacing as such creating real interlace animations (i.e. 2x25 not 1x25) can be very challenging in Amiga.

[sandruzzo]

@pandy71

With extended refresh rate, dma slots don't changes? I mean, we have more lines...

[dissident]

Originally Posted by ross

No, it is not managed this way, just checked to control also if my memory was broken
I extracted and commented the relevant code.

copperlist:
    ...
    dc.l    $FFE1FFFE
    dc.l    $0401FFFE    ; wait y==$104 position
    dc.l    $00960040    ; 'pause' blitter (CPU can be hogged by BLTPRI)
    dc.l    $009C8010    ; trigger copper IRQ
    dc.l    $01000000    ; no bpls active
    dc.l    $FFFFFFFE    ; CEND

irq3:    ...
    MOVE.W    $dff01e,D1
    BTST    #4,D1        ; copper IRQ?
    BEQ.B    .skip        ; no, skip
    MOVE.L    $dff004,D0    ; beam position
    AND.L    #$ff0000ff,D0    ; isolate LOF+I and x position
    ADD.L    #$00013610,D0    ; skip $136-$104=$32=50 lines
    MOVE.L    D0,$dff02a    ; write new position to V(H)POSW
    MOVE.W    #$8040,$dff096    ; restart blitter operation

.skip    BTST    #5,D1
    BEQ.B    .skip2
       ..VBI_handler

This also works on OCS as opposed to using BEANCON0 (which is obviously much more convenient).

Good work, ross. I know this trick since the beginning of the 90s, published in the German "Amiga Magazin". But now it's well commented and a good example how to switch the OCS from PAL into NTSC mode if needed.


BTW the cracked version of Wings of death controls via the CTRL key the switching between PAL/NTSC.

[pandy71]

Originally Posted by sandruzzo

@pandy71

With extended refresh rate, dma slots don't changes? I mean, we have more lines...

Not from chipset perspective, of course OS will be affected but DMA slots stays unchanged... just write in line for example 200 to VPOSW/VHPOSW that this is line 100 and that's all - from HW perspective it will be line 100 thus automatically counter will add those 100 lines to overall number of lines (i.e. 200+(200-100)=300 - it is amazing how flexible HW is on this area, horizontal is completely opposite.

[chb]

Originally Posted by ross

EDIT: now that comes to mind, and if I remember correctly, there is a demo that does it to make an effect with the copper!
(only a little change to x value to shift initial copper position)
But to not lost sync every other line reset the position.

I quote myself :
[ Show youtube player ]

Fast forward to 11:45.
The copper effect on the upper part.

Very interesting, thanks for the link! So copper position is compared against VHPOS, which can be changed? Didn't know that this is possible!

Are DMA and horizontal display sync also affected? So if I change horiz. position to 0 in the middle of the line, will the hardware start a new DMA cycle (refresh, audio..)? And if I set it to $0D, will it restart with audio DMA only?

[ross]

Originally Posted by chb

Very interesting, thanks for the link! So copper position is compared against VHPOS, which can be changed? Didn't know that this is possible!

Yes, can be changed, but only via CPU.
So there is a crazy code that sync in every line the CPU with BEAM position and change accordingly VHPOS.
This is because the copper cannot wait for odd positions (best precision from the mask is #$fffe), this corresponds to 4 pixels in low resolution.
But if you 'shift' the x position of a single CCK the odd position become even (this is 2 'pixels after' a normal wait)!
Therefore: before BPL DMA fetches write a value that is one CCK after video position, after the last fetch realign the position.

Are DMA and horizontal display sync also affected? So if I change horiz. position to 0 in the middle of the line, will the hardware start a new DMA cycle (refresh, audio..)? And if I set it to $0D, will it restart with audio DMA only?

No h-sync affected (in this case at least) but no idea about 'DMA slot' restart on the very line.
Pandy71 tests are discouraging..

Maybe Toni can enlighten us.