17 March 2024, 09:22 | #21 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
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 Quote:
Quote:
--- 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 |
||
17 March 2024, 10:27 | #22 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
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. |
17 March 2024, 10:53 | #23 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,919
|
Quote:
|
|
19 March 2024, 20:54 | #24 | |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 217
|
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 Quote:
Code:
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 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; Last edited by Rock'n Roll; 20 March 2024 at 21:12. Reason: formula correction |
|
20 March 2024, 09:07 | #25 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
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. Quote:
|
|
20 March 2024, 11:38 | #26 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 217
|
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 Code:
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 |
20 March 2024, 18:03 | #27 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
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. |
|
06 July 2024, 12:08 | #28 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
Quote:
Maybe the 'impossible' can be possible |
||
07 August 2024, 21:00 | #29 | |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 217
|
Quote:
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. 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? Code:
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 |
|
07 August 2024, 22:59 | #30 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
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). Quote:
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 |
|
07 August 2024, 23:39 | #31 | |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 5,154
|
Quote:
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 ! |
|
08 August 2024, 00:00 | #32 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
Quote:
It's also my pleasure, always hoping to be understood given my terrible English |
|
08 August 2024, 14:45 | #33 | |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 217
|
Quote:
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. Code:
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 |
|
08 August 2024, 15:55 | #34 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,536
|
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). |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
RTG screen size - no overscan | Angus | Retrogaming General Discussion | 9 | 01 November 2023 22:48 |
Amiga games with Hires/Interlace options... | DDNI | Retrogaming General Discussion | 40 | 05 August 2019 10:00 |
PAL Hires, but with overscan of 1024 x 384 - possible? | mingle | support.WinUAE | 21 | 21 July 2010 13:11 |
ClassicWB Full for PAL Hires Interlace? | mingle | project.ClassicWB | 1 | 16 July 2010 15:54 |
WB overscan and screen size | Marcuz | support.Apps | 0 | 20 December 2006 16:40 |
|
|