hires, interlace, overscan - max screen size?

[ross]

Originally Posted by mc6809e

Oh, c'mon. You know you want to.

The practically insurmountable obstacle in this case is that in hires there are no bus cycles available during the line.
Of course, as a proof of concept you could try decreasing the number of bitplanes, but at that point the solution would no longer be generic.
And also I have no idea what mess could happen with the match for Denise's (rewritten) counter

I have been wondering what a flat creen might do if the VHPOS is walked back 16 pixels a few times per line. HSYNC frequency would be reduced but a few displays might be able to handle it as they tune themselves to the lower frequency.

This has been tested and to some extent it works.

I'd worry about old CRTs, though. Screwing with HSYNC frequency can possibly wreck a flyback transformer.

Oh yeah, I burned (a cheap) one in the early 90's for this kind of testing... would definitely avoid doing it .

---

Going back to the hires 'coverage' issue, I also thought about the method/trick used for the lores arrangement and whether it could work in hires (i.e. forcing a new BPLCON1 with the Copper at the reset of Denise's counter at the beginning of the new line), but unfortunately in the lores case works because the shifter is already full with DMA data, which in this case I don't have.
Of course I could write with Copper or with the processor in BPL1DAT, but at that point the content of the shifter would be completely messed up (by previous data in BPLxDAT).
I could eventually try using a monochrome mode, but I don't think I would be able to synchronize the data in any case, maybe...

I have no proper solutions

[ross]

Ah, and if anyone had stumbled across this thread and wondered what these crazy people are talking about, we discuss how to use and possibly display, in a microscopic slice of video line (~0.5us), normally invisible and which may or may not be outside the tolerance of various devices and which in any case is useless and unused, a tiny handful of pixels in a video mode that is not normally used for this kind of visualization.
Obviously I'm in the front line of these old fools, but I find the fact that there are others in line absolutely hilarious and satisfying .

I obviously don't want to offend anyone present, but I often wonder if I'm the only one who spends some time thinking about these things and seeing someone else in the same boat brings a smile to my face.
Possibly the question could be broadened a bit to all the topics of the forum, but at this point we would be going very far off the mark .
[of course the answer is trivial: it's called the pleasure of doing your hobbies, but let's pretend we don't know the answer]

Sorry for the OT.

[pandy71]

Originally Posted by mc6809e

I have been wondering what a flat creen might do if the VHPOS is walked back 16 pixels a few times per line. HSYNC frequency would be reduced but a few displays might be able to handle it as they tune themselves to the lower frequency.

I'd worry about old CRTs, though. Screwing with HSYNC frequency can possibly wreck a flyback transformer.

I see no point to use modern displays as they are programmed to accept few fixed modes - most of them on SCART or CVBS/S-Video input only use ITU sampling i.e. 13.5 MHz (usually it is 27MHz due needs of signal processing and some other limitations) - So even if they can sync then anyway they will perform improper signal processing from Amiga perspective unless they are programmed specially for Amiga signal properties.

[Rock'n Roll]

1) dc.w $8e,$1c59,$90,$38c1,$92,$28,$94,$d4 ; 720x 45x16 (mod 90) works
2) dc.w $8e,$1c61,$90,$38c9,$92,$2c,$94,$d8 ; 720x 45x16 (mod 90) doesn't works
6) dc.w $8e,$1c51,$90,$38c9,$92,$24,$94,$d8 ; 752x 47x16 (mod 94) doesn't works

Originally Posted by ross

So regarding your cases:
1) this is actually a 46*16, with stop at $D8
2) this is actually a 46*16, with stop at $DC -> an overrun!, a real machine most likely crash here
6) same as 2) but a 48*16

some mathematics please! I get the same results!

1)
>?$d4-$28 -> $000000AC = %00000000`00000000`00000000`10101100 = 172 = 172	; x=DDFSTOP-DDFSTRT
>?172/8 -> $00000015 = %00000000`00000000`00000000`00010101 = 21 = 21		; n=(DDFSTOP-DDFSTRT)/8 (this formula is not in all cases correct) look bottom
>?4+2*21 -> $0000002E = %00000000`00000000`00000000`00101110 = 46 = 46		; sub-blocks=4+2*n
>?$28+21*8+8 -> $000000D8 = %00000000`00000000`00000000`11011000 = 216 = 216	; DDFSTOP=DDFSTRT+n*8+8
>?46*16 -> $000002E0 = %00000000`00000000`00000010`11100000 = 736 = 736		; pixel per line=sub-blocks*16px

2) 
>?$d8-$2c -> $000000AC = %00000000`00000000`00000000`10101100 = 172 = 172
>?172/8 -> $00000015 = %00000000`00000000`00000000`00010101 = 21 = 21
>?4+2*21 -> $0000002E = %00000000`00000000`00000000`00101110 = 46 = 46
>?$2c+21*8+8 -> $000000DC = %00000000`00000000`00000000`11011100 = 220 = 220

6)
>?$d8-$24 -> $000000B4 = %00000000`00000000`00000000`10110100 = 180 = 180
>?180/8 -> $00000016 = %00000000`00000000`00000000`00010110 = 22 = 22
>?4+2*22 -> $00000030 = %00000000`00000000`00000000`00110000 = 48 = 48
>?$24+22*8+8 -> $000000DC = %00000000`00000000`00000000`11011100 = 220 = 220
>?48*16 -> $00000300 = %00000000`00000000`00000011`00000000 = 768 = 768

Then, the WinUAE DMA Debugger shows the info about 0 for DDFSTRT, and 1 or 2 for DDFSTOP.
1.) What's the different between 1 and 2 and why stands 2 on D7 and not on D8?
2.) LOF=1/1 HDIW=1 VDIW=1 or LOF=0/0 HDIW=1 VDIW=1.
Why not only LOF=0 or LOF=1? and what about HDIW=1, VDIW=1?

Edit: with this programlines I get in all 7 cases the same results as ross
int n=round((float(DDFSTOP)-float(DDFSTRT))/8)-1;
int sub_blocks=4+2*n;
int DDFSTOP_ex=DDFSTRT+n*8+8;
int pixel_fetch=sub_blocks*16;

[ross]

Originally Posted by Rock'n Roll

some mathematics please! I get the same results!

Sorry, I'm not sure if this is a question/request or a statement.
Are you asking me for a mathematical 'proof' for my statements, or are you telling me that even with your values you get the same results?
In both cases you will find the explanation of the issue in the thread where I 'define' a formula for these calculations regarding DDFs.
It all boils down to the fact that there is no bijective function that provides single results, you can use different values and have the same effects because the hardware doesn't work by 'parameters' but by 'comparisons' between counters and registers and execution duration, so the various granularities lead to the possibility of using 'ranges' of values and not noticing differences in results.
Ok ok, abstract speeches, but if you give me a single example/data I will clarify it completely.

Then, the WinUAE DMA Debugger shows the info about 0 for DDFSTRT, and 1 or 2 for DDFSTOP.
1.) What's the different between 1 and 2 and why stands 2 on D7 and not on D8?
2.) LOF=1/1 HDIW=1 VDIW=1 or LOF=0/0 HDIW=1 VDIW=1.
Why not only LOF=0 or LOF=1? and what about HDIW=1, VDIW=1?

I did not understand

[Rock'n Roll]

It was a statement and not a question.
I came up with the same values mathematically as they did and I only need it to be "roughly" accurate for my understanding and not "super" accurate.
So, if I understood it 99% it's ok for me. (The formula helps me to understand the connections, but it is probably too imprecise for your world view.)

The questions were related to the WinUAE debugger output:
Maybe some background information about:
1.) What's the different between 1 and 2 and why stands 2 on D7 and not on D8?
2.) LOF=1/1 HDIW=1 VDIW=1 or LOF=0/0 HDIW=1 VDIW=1. Why not only LOF=0 or LOF=1? and what about HDIW=1, VDIW=1?

>c
...
BPLCON 0: $9204 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=1 VDIW=1

and the '1' and '2' as indication for DDFSTOP

Line: 2C  44 HPOS D0 208:
 [D0     -]   [D1     -]   [D2     -]   [D3     -]   [D4     -]   [D5     -]   [D6     -]   [D7     -]
                                        BPL1   110                                          BPL1   110
                                              0000   1                                            0000
                                          0006A570                                            0006A572

                                         1B8   152                                           1B9   152

or 
>v $2c $d0
Line: 2C  44 HPOS D0 208:
 [D0     -]   [D1     -]   [D2     -]   [D3     -]   [D4     -]   [D5     -]   [D6     -]   [D7     -]
                                        BPL1   110                                          BPL1   110
                                              0000                                           2    0000
                                          0006B128                                            0006B12A

                                         194   158                                           195   158

[ross]

Originally Posted by Rock'n Roll

It was a statement and not a question.
I came up with the same values mathematically as they did and I only need it to be "roughly" accurate for my understanding and not "super" accurate.
So, if I understood it 99% it's ok for me. (The formula helps me to understand the connections, but it is probably too imprecise for your world view.)

The questions were related to the WinUAE debugger output:
Maybe some background information about:
1.) What's the different between 1 and 2 and why stands 2 on D7 and not on D8?
2.) LOF=1/1 HDIW=1 VDIW=1 or LOF=0/0 HDIW=1 VDIW=1. Why not only LOF=0 or LOF=1? and what about HDIW=1, VDIW=1?

>c
...
BPLCON 0: $9204 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=1 VDIW=1

and the '1' and '2' as indication for DDFSTOP

Line: 2C  44 HPOS D0 208:
 [D0     -]   [D1     -]   [D2     -]   [D3     -]   [D4     -]   [D5     -]   [D6     -]   [D7     -]
                                        BPL1   110                                          BPL1   110
                                              0000   1                                            0000
                                          0006A570                                            0006A572

                                         1B8   152                                           1B9   152

or 
>v $2c $d0
Line: 2C  44 HPOS D0 208:
 [D0     -]   [D1     -]   [D2     -]   [D3     -]   [D4     -]   [D5     -]   [D6     -]   [D7     -]
                                        BPL1   110                                          BPL1   110
                                              0000                                           2    0000
                                          0006B128                                            0006B12A

                                         194   158                                           195   158

>c command:
1: $xxxx = BPLCON1;
2: $xxxx = BPLCON2;
LOF=X/Y: X = LOF that display think it is, Y = actual LOF state inside Agnus.
(you can change LOF bit in Agnus many times during the frame, but the signals with which the frame is defined are used uniquely in VSYNC);
HDIW=0/1 HDIW open or not;
VDIW=0/1 VDIW open or not

In the DMA debugger:
[1] = DDFSTOP match caused last bitplane 'block' state;
[2] = DDF hard stop (or DDFSTRT==DDFSTOP) caused last bitplane 'block' state.

[ross]

Originally Posted by mc6809e

Oh, c'mon. You know you want to.

Originally Posted by ross

The practically insurmountable obstacle in this case is that in hires there are no bus cycles available during the line.
Of course, as a proof of concept you could try decreasing the number of bitplanes, but at that point the solution would no longer be generic.
And also I have no idea what mess could happen with the match for Denise's (rewritten) counter

I have no proper solutions

Something has been cooking in the pot in recent months...

Maybe the 'impossible' can be possible

[Rock'n Roll]

Originally Posted by ross

LOF=X/Y: X = LOF that display think it is, Y = actual LOF state inside Agnus.
(you can change LOF bit in Agnus many times during the frame, but the signals with which the frame is defined are used uniquely in VSYNC);

1. Why should I change the LOF-Bit?
2. I have actually seen LOF 0/1 in addition to LOF 1/1 and LOF 0/0, but I still don't understand what it depends on?
I went on frame by frame in the interlace screen.

Originally Posted by ross

HDIW=0/1 HDIW open or not;
VDIW=0/1 VDIW open or not

I would have guessed that HDIW and VDIW are always 1 if they are within the DIWSTRT, DIWSTOP limits.
3. This works for VDIW, but not for HDIW?

DIWSTRT: $2c81 DIWSTOP: $2cc1 DDFSTRT: $0038 DDFSTOP: $00d0

>fs $2b $0
DMACON: $23f0 INTENA: $202c ($202c) INTREQ: $1068 ($1068) VPOS: 043 ($02b) HPOS: 009 ($009)
BPLCON 0: $3200 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=1 VDIW=0	; VDIW=0 ok

>fs $12d $0
DMACON: $23f0 INTENA: $202c ($202c) INTREQ: $1068 ($1068) VPOS: 301 ($12d) HPOS: 018 ($012)
BPLCON 0: $3200 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=0 VDIW=0	; VDIW=0 ok	

>fs $90 $0
DMACON: $23f0 INTENA: $202c ($202c) INTREQ: $1068 ($1068) VPOS: 144 ($090) HPOS: 006 ($006)
BPLCON 0: $3200 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=1 VDIW=1	; VDIW=0 ok, HDIW=1 ???

>fs $90 $90
DMACON: $23f0 INTENA: $202c ($202c) INTREQ: $1068 ($1068) VPOS: 144 ($090) HPOS: 156 ($09c)
BPLCON 0: $3200 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=0 VDIW=1	; HDIW=0 not ok

>fs $90 $d0
DMACON: $23f0 INTENA: $202c ($202c) INTREQ: $1068 ($1068) VPOS: 144 ($090) HPOS: 209 ($0d1)
BPLCON 0: $3200 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=0 VDIW=1	; HDIW=0 would be ok

>fs $90 $A0
DMACON: $23f0 INTENA: $202c ($202c) INTREQ: $1068 ($1068) VPOS: 144 ($090) HPOS: 178 ($0b2)
BPLCON 0: $3200 1: $0000 2: $0000 3: $0c00 4: $0011 LOF=1/1 HDIW=0 VDIW=1	; HDIW=0 not ok

[ross]

Originally Posted by Rock'n Roll

1. Why should I change the LOF-Bit?

Usually you don't have to do this, because the normal interlace can easily rely on the LACE bit in BPLCON0, which is an auto-toggle (at the end of the frame a LOF ^= LACE is performed).
But nothing prevents you from manually selecting short frames (LOF=0) or long frames (LOF=1).

2. I have actually seen LOF 0/1 in addition to LOF 1/1 and LOF 0/0, but I still don't understand what it depends on?

As I wrote to you in a previous message:

LOF=X/Y: X = LOF that display think it is, Y = actual LOF state inside Agnus.
(you can change LOF bit in Agnus many times during the frame, but the signals with which the frame is defined are used uniquely in vsync);

I don't know if I can explain it better but I try.

The Agnus circuitry is responsible for building the signals during vsync that allow the display device to understand what type of frame to use (for old CRT monitors the exact starting vertical position and what the dominant field is, also useful for digital devices to build the correctly interlaced frame).

But the LOF state can be changed at will during the frame, without having any visible effect, because it is its instantaneous state during vsync that defines which pulses to 'build'.
This implies that there will be an internal state (readable and writable) and an instantaneous used state, and this is what WinUAE tells you.

My advice is to let the hardware handle the situation, because you need to know exactly what you're doing before touching these bits

[malko]

Originally Posted by ross

Ah, and if anyone had stumbled across this thread and wondered what these crazy people are talking about, we discuss how to use and possibly display, in a microscopic slice of video line (~0.5us), normally invisible and which may or may not be outside the tolerance of various devices and which in any case is useless and unused, a tiny handful of pixels in a video mode that is not normally used for this kind of visualization.
Obviously I'm in the front line of these old fools, but I find the fact that there are others in line absolutely hilarious and satisfying .

I obviously don't want to offend anyone present, but I often wonder if I'm the only one who spends some time thinking about these things and seeing someone else in the same boat brings a smile to my face.
Possibly the question could be broadened a bit to all the topics of the forum, but at this point we would be going very far off the mark .
[of course the answer is trivial: it's called the pleasure of doing your hobbies, but let's pretend we don't know the answer]

Sorry for the OT.

Amiga knowledge speaking, I'm clearly rowing behind your boat, but reading your explanations (even the more technical ones - which sometimes leave me at a loss as to how much I don't know about the subject I'm reading about ) is a pleasure that helps us/me to gain knowledge. So !

[ross]

Originally Posted by Rock'n Roll

I would have guessed that HDIW and VDIW are always 1 if they are within the DIWSTRT, DIWSTOP limits.
3. This works for VDIW, but not for HDIW?

I have no idea if HDIW is really open in those positions (you would need to see the code in action and the values of DIWxxxx registers are not enough), but if there is some problem it can always be fixed.

Originally Posted by malko

..is a pleasure that helps us/me to gain knowledge..

It's also my pleasure, always hoping to be understood given my terrible English

[Rock'n Roll]

Originally Posted by ross

It's also my pleasure, always hoping to be understood given my terrible English

your answers and also your english is quite perfect.

one remark from my side:
DMA debugger uses the second refresh slot to show if line is used for long field (F) and long line (L). The 'F' is showed. The 'L' is missed.
I would have expected a 'fixed' point in time, e.g. Denise $1c7 or HPOS $5, at which it changes from LOF 0/1 or LOF 1/0 to LOF 1/1 or LOF 0/0,
but in my test the change only occurs between HPOS $d and $11. But basically I am satisfied with the answer.

Line: 00   0 HPOS 00   0:
 [00 1BE -]   [01 1C0 -]   [02 1C2 -]   [03 1C4 -]   [04 1C6 -]   [05 002 -]   [06 004 -]   [07 006 -]
                                        RFS0   03A   COP    08C   RFS1   1FE   COP    08C   RFS2   1FE
                                                *B    C    FFFF           *F         00E0

another contribution to the LOF bit: https://eab.abime.net/showpost.php?p...8&postcount=23

[ross]

Originally Posted by Rock'n Roll

DMA debugger...

Just a small note.
Don't take the DMA debugger at face value

It's pretty much a work in progress and in the next version of WinUAE there will be some (nice!) changes and improvements.
Of course, there are no major errors, but some details could be slightly fixed in future.

It helps incredibly in understanding the inner workings, but many things have been 'discovered', or better said 'understood', only recently.

So sometimes you might find small inconsistencies or simply details out of place (anyway report them ).
Also LOF and how and where it operates on pulses and how vsync and other related signals behave is a very recent question (and in the process of being fully implemented).