English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 21 July 2018, 18:11   #61
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by Toni Wilen View Post
You meant that unexplained tiny DIWSTRT/DIWSTOP DDFSTRT/DDFSTOP region set at the beginning of copper list? Yes, I agree that it must be some buggy chipset workaround.
Yes, that.
Another oddity is the $00E0,$0000 at copper list start (no reason for this..).

Last edited by ross; 21 July 2018 at 18:54. Reason: I've moved the unrelated part
ross is offline  
AdSense AdSense  
Old 21 July 2018, 19:01   #62
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 22
So finally, thanks to all the help in this thread (which is really appreciated - thank you Toni and ross!), I have everything lining up nicely on AGA.

For anyone following the thread who might find it useful, the end result of all this, to have OCS and AGA match, I added the following (after the normal diwstart/stop stuff):
Code:
if ( System_IsAGA() )
{
    CopperList_Move( c, BPLCON0, bplCon0 | 0x1 ); // ECSENA active for BRDRBLNK
    CopperList_Move( c, BPLCON3, 0x20 );  // Enable BRDRBLNK (fix right side)
    CopperList_Move( c, DIWHIGH, 0x2010 );// Start half pixel later (fix left side)
}
else
{
    CopperList_Move( c, BPLCON0, bplCon0 ); // Normal BPLCON0 on OCS/ECS
}
This means on AGA only:
  • the window starts one half lores pixel later (70ns). This makes the left edge of bitplane and sprite data line up with the COLOR00 change from the copper which is delayed by 70ns
  • the window is clipped on the right side by BRDRBLNK. This clips half a lowres pixel (70ns) off bitplane/sprite data due to BRDRBLNK being applied 70ns too early, but it clips COLOR00 at the same place so it lines up
  • I lose a pixel of display data in total, but it's a nice symmetrical half pixel from either side and looks good. You can barely tell the half pixels are missing, as opposed to the misalignment which was immediately visible)

I have not tested this on ECS, but based on Toni's comment about the delay being AGA specific, this hopefully works correctly on ECS as well (by using the normal OCS settings). I will test it next time I can access an A600.

Since this fix is quite non-intrusive, it could probably be retroactively applied to titles like Shadow of the Beast if desired.
FSizzle is offline  
Old 21 July 2018, 19:22   #63
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by FSizzle View Post
So finally, thanks to all the help in this thread (which is really appreciated - thank you Toni and ross!), I have everything lining up nicely on AGA.

For anyone following the thread who might find it useful, the end result of all this, to have OCS and AGA match, I added the following (after the normal diwstart/stop stuff):
Code:
if ( System_IsAGA() )
{
    CopperList_Move( c, BPLCON0, bplCon0 | 0x1 ); // ECSENA active for BRDRBLNK
    CopperList_Move( c, BPLCON3, 0x20 );  // Enable BRDRBLNK (fix right side)
    CopperList_Move( c, DIWHIGH, 0x2010 );// Start half pixel later (fix left side)
}
else
{
    CopperList_Move( c, BPLCON0, bplCon0 ); // Normal BPLCON0 on OCS/ECS
}
This means on AGA only:
  • the window starts one half lores pixel later (70ns). This makes the left edge of bitplane and sprite data line up with the COLOR00 change from the copper which is delayed by 70ns
  • the window is clipped on the right side by BRDRBLNK. This clips half a lowres pixel (70ns) off bitplane/sprite data due to BRDRBLNK being applied 70ns too early, but it clips COLOR00 at the same place so it lines up
  • I lose a pixel of display data in total, but it's a nice symmetrical half pixel from either side and looks good. You can barely tell the half pixels are missing, as opposed to the misalignment which was immediately visible)

I have not tested this on ECS, but based on Toni's comment about the delay being AGA specific, this hopefully works correctly on ECS as well (by using the normal OCS settings). I will test it next time I can access an A600.

Since this fix is quite non-intrusive, it could probably be retroactively applied to titles like Shadow of the Beast if desired.
Well done

Only two little details:
Code:
BRDRBLNK
    CopperList_Move( c, BPLCON3, 0x0C20 );  // Enable BRDRBLNK (fix right side)
because you need default color table to be compatible with OCS/ECS
and
Code:
 CopperList_Move( c, DIWHIGH, 0x2110 );// Start half pixel later (fix left side)
for a DIW compatible with PAL screen (but logically depends on screen/game).
ross is offline  
Old 22 July 2018, 07:45   #64
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 22
Code:
you need default color table to be compatible with OCS/ECS
This only seems to relate to dual playfield setup, but I think it makes sense to drive these to defaults, so I've done that.

Quote:
for a DIW compatible with PAL screen (but logically depends on screen/game).
In my case i'm driving an NTSC display, but I added a comment to my code because if I need PAL in the future, I'm sure to forget about this

Thanks!
FSizzle is offline  
Old 22 July 2018, 13:07   #65
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,509
I started adding DIWHIGH H0/H1 start/end bit support. But I need some test programs to validate it, my own tests (when using my own test programs) are rarely not that good
Toni Wilen is online now  
Old 22 July 2018, 15:27   #66
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by Toni Wilen View Post
I started adding DIWHIGH H0/H1 start/end bit support. But I need some test programs to validate it, my own tests (when using my own test programs) are rarely not that good
Ok, I'm writing a test program.

But found another strangeness..
I'm using SHRES bit of BPLCON0 with FMODE=0 for an AGA/ECS testbed and i've the right part [and left if DIWSTRT is covering some pixels] of video not showing.
After some found that DIWSTOP=xxC8 is accepted! (yes, i'm not using DIWHIGH, BEAMCON0 or other advanced registers).
Changing to HIRES or LORES and leaving xxC8 let the horizontal borders (left and right) is opened like usual.

Is this an AGA feature? (that I didn't know absolutely..)

Last edited by ross; 22 July 2018 at 15:49. Reason: []
ross is offline  
Old 22 July 2018, 16:34   #67
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,509
How much you can increase it until full overscan opens? C9?

Superhires does have some odd side-effects, like disabling DDFSTRT/STOP limits but I haven't noticed this previously.

winuae.7z possibly handles DIWHIGH H0/H1 now but not really tested and there still may be some parts that assume lores pixels.
Toni Wilen is online now  
Old 22 July 2018, 17:47   #68
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Sorry Toni if I do not specify it all the times, but all my tests are in WinUAE (i've not a real machine).
Quote:
Originally Posted by Toni Wilen View Post
How much you can increase it until full overscan opens? C9?
Full overscan open at C8.
Quote:
Superhires does have some odd side-effects, like disabling DDFSTRT/STOP limits but I haven't noticed this previously.
Ok

Quote:
winuae.7z possibly handles DIWHIGH H0/H1 now but not really tested and there still may be some parts that assume lores pixels.
Ok, i'll test it.
Not releasing a binary because i've a strange video effect (still in shres): with some shift values there are pixels visible after DIWSTOP position.. but can a bug in my code.

Last edited by ross; 22 July 2018 at 19:07.
ross is offline  
Old 22 July 2018, 17:49   #69
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,509
These kinds of test programs must be done and tested on real hardware first.

EDIT: UAE has specific test for "HARD_DDF_LIMITS_DISABLED" state (=BEAMCON bit 7 or bit 14 set or BPLCON0 SuperHires bit) which changes how display window end detection is done. Unfortunately I am not sure if it is correct or not

EDIT2: Change log entry: "Reset horizontal display window if it is still active at the end of scanline (even if it is
larger than last hpos value) if programmed mode or superhires. Perhaps this is wrong, perhaps not,
not bothered to test yet.. (Background "leak" in right edge in some wide programmed mode screens)"

Probably never confirmed..

I guess test code that does not try any tricks is good, even if it is not real hardware tested. Maybe.

Last edited by Toni Wilen; 22 July 2018 at 18:19.
Toni Wilen is online now  
Old 22 July 2018, 18:29   #70
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Ok, made a little test for the shres open border WinUAE behaviour.
SHRES=1, 1024 pixels wide screen from DDFSTRT=4e

In a real machine you could see it like this, maybe..:


In WinUAE you see:


DIWSTRT is set to xxff, DIWSTOP to xxca

With right mouse you decrease DIWSTOP value.
After some click in a real machine (when value reached c7) you should see the same as Winuae..

---

EDIT: executable removed, Toni fixed the problem in new WinUAE version, thanks
Attached Thumbnails
Click image for larger version

Name:	shresover1.png
Views:	121
Size:	324 Bytes
ID:	58969   Click image for larger version

Name:	shresover2.png
Views:	118
Size:	295 Bytes
ID:	58970  

Last edited by ross; 25 July 2018 at 10:35. Reason: new WinUAE fix for this
ross is offline  
Old 22 July 2018, 18:45   #71
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by ross View Post
with some shift values there are pixels visible after DIWSTOP position.. but can a bug in my code.
Yes, my bug. High shift bits are masked out in (s)hires video modes and there is a early roll of LUT values

Quote:
Originally Posted by Toni Wilen View Post
I guess test code that does not try any tricks is good, even if it is not real hardware tested. Maybe.
I disagree Trying some tricks is one of Amiga's funniest things.
ross is offline  
Old 22 July 2018, 18:49   #72
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,509
I didn't ask for superhires border test programs. I asked for DIWHIGH H0/H1 bit test programs (because pixel counting is annoying and easy to make mistakes). Testing it this way is pointless speculation because real hardware test is extremely simple (Which I do in next few days) and quick and results must not be assumed when it is about undocumented features.

And as usual, "does not work" is not acceptable, works for me.

Quote:
I disagree. Trying some tricks is one of Amiga's funniest things.
I said I am not going to accept any test programs (using tricks) made for testing emulation without real hardware test. It would be pointless.
Toni Wilen is online now  
Old 22 July 2018, 19:02   #73
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by Toni Wilen View Post
And as usual, "does not work" is not acceptable, works for me.
Sorry, for some reason i've downloaded a wrong version (the 22/07 version report the same 21/07 date).
In this version BPLCON1(H1/H0) work properly.
Please wait a test binary.

Quote:
I said I am not going to accept any test programs (using tricks) made for testing emulation without real hardware test. It would be pointless.
Like i've said was an involuntary trick, that made me loss even some time.

Last edited by ross; 22 July 2018 at 21:52.
ross is offline  
Old 22 July 2018, 21:44   #74
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
I'm sorry but it does not work well for me (version dated 22/07 16:35).
EDIT: because i'm dumb, wrong bits selected..

I've checked the code several times but this certainly does not rule out that it may be a bug on my part.
EDIT: yes, looked several times and always looked wrong..
Not being able to try on my own real machine is frustrating.

The binary values: DIWSTRT=30a1, DIWSTOP=00a1, DIWHIGH=2100, DDFSTRT=004e, DDFSTOP=00c6, BPLCON0=1240
Some copper color0 synced with DIWSTRT -> works properly (you can notice that this time color0 is before bplanes because the DDFSTRT value)
Right mouse click increment shift value by quarter pixel -> work properly
Left mouse click increment DIWSTRT/STOP by quarter pixel -> do not works properly
EDIT: yes works if you use the right bits...
Exit with both mouse buttons pressed.
EDIT: updated executable on message #79

I've also a visible "ghost" problem on workbench at max overscan (not present in previous versions).
And unfortunately I continue to have several problems with the integrated debugger.
Ok, today is not a good day with the Amiga.
EDIT: it would have been better to go for a walk
Attached Thumbnails
Click image for larger version

Name:	wgh.png
Views:	24
Size:	2.7 KB
ID:	58975  

Last edited by ross; 23 July 2018 at 18:12.
ross is offline  
Old 23 July 2018, 13:46   #75
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,509
DIWHIGH H0/H1 bits seem to work as expected in my quick test code (of course with subpixel checkbox ticked). I also can't find anything wrong with BPLCON1.

("max overscan" is mostly meaningless because copper list contents depends on resolution, number of colors, WB version and more.. Reason I usually require program that takes over the system)
Toni Wilen is online now  
Old 23 July 2018, 16:55   #76
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by Toni Wilen View Post
DIWHIGH H0/H1 bits seem to work as expected in my quick test code (of course with subpixel checkbox ticked). I also can't find anything wrong with BPLCON1.
DIWHIGH H0/H1 doesn't work as expected in my exe from message #74 (can be my fault).
In same message I confirm that BPLCON1 is working properly (shift value by quarter pixel is working properly).
Of course with subpixel checkbox ticked, Host/Display/Resolution as SuperHires, Host/Filter Null,No scaling,H/V=1x.

Quote:
("max overscan" is mostly meaningless because copper list contents depends on resolution, number of colors, WB version and more.. Reason I usually require program that takes over the system)
This is easily reproducible.
Quickstart A1200 setup (020, no fastmem, but doesn't matter), default KS31/WB31 setup (like a first installation), no extra fancies, PAL Hires screen at max ovescan (724x) with standard Prefs prog, numbers of colours do not matter, subpixel and SuperHires active, no scaling.
The ghost effect is visible like message #74. If you disable subpixel or superhires, glitch is no more.
ross is offline  
Old 23 July 2018, 17:21   #77
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,509
I don't think your test program is setting DIWHIGH correctly, originally it is $2100 (default), one click and it becomes $2504 which does not make any sense. (V8 and V10 start bits set, V10 stop bit set).
Toni Wilen is online now  
Old 23 July 2018, 17:28   #78
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Quote:
Originally Posted by Toni Wilen View Post
I don't think your test program is setting DIWHIGH correctly, originally it is $2100 (default), one click and it becomes $2504 which does not make any sense. (V8 and V10 start bits set, V10 stop bit set).
aaargh, i've used the wrong bits!
I reassemble immediately a proper version.
Sorry
ross is offline  
Old 23 July 2018, 17:37   #79
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
Attached a working version.
My apologies Toni.


EDIT: I can also confirm that works like a charm in my patched Lionheart version.
That have a really delirantic copper list, BPLICON1 abuse and code that race the video beam.
No glitch anywhere.
Attached Files
File Type: zip shdiw_w.zip (831 Bytes, 6 views)

Last edited by ross; 23 July 2018 at 18:22.
ross is offline  
Old 23 July 2018, 19:28   #80
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 932
More info about the "ghost" glitch.

It's related to ddfstrt/ddfstop values: the max wide fetch ($18/$d8) generate the problem.
Any lower set (like $28/$d8 or $18/$c8, wb use these) do not create glitch.
And ghosted image seems containg only data from bitplanes 2,4,6,8.
ross is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Needed: A1200 Delay Line & Bandpass Filter PARALAX support.Hardware 0 04 December 2016 18:44
A1200 reset delay Cobe support.Hardware 18 09 May 2016 18:31
Alien Breed II title pixel by pixel logo removal dex project.Sprites 15 18 August 2015 11:06
Problem running copper master demo on A1200 whitebird support.Demos 26 17 August 2014 17:41
Wanted - A1200 Tin Shield Bottom Half - NEW Peter MarketPlace 0 15 September 2010 17:06

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:10.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.08792 seconds with 14 queries