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.