English Amiga Board


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

 
 
Thread Tools
Old 09 September 2009, 23:23   #41
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Could you try something simple Toni (on real hardware and compare with emu) and see if you get the same results as me? Take over hardware, set a new int ptr (in my case, VBL), and in the int you have a counter that is increased each time it's called.

No matter how many times I clear requests (just before, just after setting the vector, or both) the counter is never 0 when AsmOne debugger hits it first time.

In my case, the int is set just before VBL (rasterline $132 or something), so I'm sure the hardware has no reason to call it once before the VBL and once when the VBL occurs a few rasterlines later...
Photon is offline  
Old 09 September 2009, 23:27   #42
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Quote:
Originally Posted by Photon View Post
Could you try something simple Toni (on real hardware and compare with emu) and see if you get the same results as me? Take over hardware, set a new int ptr (in my case, VBL), and in the int you have a counter that is increased each time it's called.

No matter how many times I clear requests (just before, just after setting the vector, or both) the counter is never 0 when AsmOne debugger hits it first time.

In my case, the int is set just before VBL (rasterline $132 or something), so I'm sure the hardware has no reason to call it once before the VBL and once when the VBL occurs a few rasterlines later...
Not enough information and I do not trust any debuggers. (or you have JIT enabled or something) Also, this can't happen because it would break too many programs
Toni Wilen is online now  
Old 09 September 2009, 23:28   #43
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,146
Quote:
Originally Posted by Photon View Post
No matter how many times I clear requests (just before, just after setting the vector, or both) the counter is never 0 when AsmOne debugger hits it first time.
How do you check the counter? It definitely has to be 0 one time or there is some bug in your code. Just do a simple
Code:
    move.l counter(pc),d0
    beq.b .is_zero
  ...

.is_zero move.w #$f00,$dff180
            bra.b .is_zero
in your VBL and you should get the infamous RSOD.
StingRay is offline  
Old 11 September 2009, 00:17   #44
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Red Screen Of Debugging.

The reason I posted this at all was that I couldn't see any problems with the few lines in question. Will probably reveal some interesting behavior, I'll look into it.

And Toni, this is on an A500 OCS/kick 2.0, AsmOne 1.02E debugger.
Photon is offline  
Old 26 September 2009, 21:04   #45
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Another undocumented feature I found today (I am sure someone else must have found this long long time ago..)

If HPOS equals horizontal DIWSTOP when COLOR0 (background) is written by copper, change is visible after extra delay of 2 lores pixels.

This explains Leander "border" (in right side) which can't be possible without undocumented features

(edit: it may not be that simple after all but clearly there is "impossible" 2 lores pixel difference)

EDIT2: above explanation is totally wrong (as usual). Extra 2 lores pixel position is always in same horizontal position (even without bitplanes disabled) so I think this is the position for "extra" 0.5 cycle (PAL is 227.5 color clocks) that causes the delay. Argh, half-cycles require hacks..

EDIT3: in NTSC mode (long/short line toggle active) there is nice "sawtooth" pattern which confirms it really is end of line "syncronization point".

Last edited by Toni Wilen; 27 September 2009 at 13:46.
Toni Wilen is online now  
Old 26 September 2009, 23:42   #46
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 41
Posts: 7,824
Send a message via MSN to dlfrsilver
Wouah nice finding Toni
dlfrsilver is offline  
Old 02 October 2009, 14:52   #47
yaqube
Registered User
 
Join Date: Mar 2008
Location: Poland
Posts: 158
Hi Toni,

The problem observed by you is caused by an "unusable" cycle for the copper. Since the copper uses every other cycle and every scan line has odd number of memory access cycles (at least in PAL) there is a situation when two accesses could happen back to back. In such a case one of these cycles is "blocked".

If the copper wants to access the memory bus two cycles before the first refresh slot that access is not performed (e.g. colour register is not written) but the actual transfer takes place in the next cycle (the one before the first refresh cycle). Since every memory access takes two low resolution pixels the observed delay is of that amount. Also the opcode fetch is affected by this behaviour and the "empty" cycles in WAIT and SKIP instructions.

Interesting thing is that the /DBR is set in this "blocked" cycle effectively blocking any potential blitter or CPU access (this is important for cycle exact emulation). The RGA bus is idle.

This cycle is not existent for the copper except one situation:

When COPJMPx register is written the copper fetches its next opcode in the second cycle after write or misses that cycle by being blocked by higher priority DMA access.

Next it requires a bus access to reload its program counter from location register. Actually there is no data transfer to/from the memory but the /DBR is set to allow the internal transfer of location register (the DMA pointer registers share the same ALU to manipulate them that's why there can't be any other DMA transfer). The RGA is idle during this cycle.

If the second cycle after COPJMPx write is the aforementioned second cycle before the first refresh cycle it's counted as usable and the copper pointer register is updated in the next cycle. During both these cycles the /DBR is set and the RGA is idle.

Below there is attached a screen shot illustrating described bus accesses.

The copper executes following program:
MOVE #$0FFF,COLOR0 ($180)
MOVE #$0000,COLOR0 ($180)
MOVE #$0000,COPJMP1 ($088)
($08C is the copper instruction register)
Attached Thumbnails
Click image for larger version

Name:	copper_E2.jpg
Views:	668
Size:	167.2 KB
ID:	22882  
yaqube is offline  
Old 03 October 2009, 13:02   #48
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Quote:
Originally Posted by yaqube View Post
Hi Toni,

The problem observed by you is caused by an "unusable" cycle for the copper. Since the copper uses every other cycle and every scan line has odd number of memory access cycles (at least in PAL) there is a situation when two accesses could happen back to back. In such a case one of these cycles is "blocked".
Thanks, this explains the "problem" perfectly. I guess this could be called some kind of copper's real "starting point"?

EDIT: this can explain few demos that have copper waits like 32DF FFFE + move. (which should be the exact position that causes 1 cycle delay and also slowing down the blitter by 1 cycle)

Last edited by Toni Wilen; 03 October 2009 at 18:13.
Toni Wilen is online now  
Old 06 October 2009, 01:07   #49
yaqube
Registered User
 
Join Date: Mar 2008
Location: Poland
Posts: 158
I have made some tests in the NTSC mode. It seems that during long lines (228 CCK long) there is no "unusable" or "blocked" cycles. All 114 cycles are usable by the copper if not blocked by the bitplane DMA.
Attached Thumbnails
Click image for larger version

Name:	copper_long.jpg
Views:	447
Size:	146.6 KB
ID:	22903  
yaqube is offline  
Old 12 October 2009, 17:56   #50
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Quote:
Originally Posted by Toni Wilen View Post
Thanks, this explains the "problem" perfectly. I guess this could be called some kind of copper's real "starting point"?

EDIT: this can explain few demos that have copper waits like 32DF FFFE + move. (which should be the exact position that causes 1 cycle delay and also slowing down the blitter by 1 cycle)
I think it was chosen early on as "the first position outside the right edge of a normal screen" where you could change COLOR00, bitplane-pointers,modulo etc without it showing - and if you had a lot of MOVEs for that wait, it gave the max amount of time to fit them in before left edge of next line.
Photon is offline  
Old 12 October 2009, 19:09   #51
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Quote:
Originally Posted by Photon View Post
I think it was chosen early on as "the first position outside the right edge of a normal screen" where you could change COLOR00, bitplane-pointers,modulo etc without it showing - and if you had a lot of MOVEs for that wait, it gave the max amount of time to fit them in before left edge of next line.
Except it isn't outside of right edge, far from it..

You need to wait for next line's hpos 3 or 7 (I forgot again) or you will see color change on far right border (real A500 + 1081-style monitor with adjusted width)
Toni Wilen is online now  
Old 12 October 2009, 20:29   #52
pmc
rebooting...
pmc's Avatar
 
Join Date: Apr 2007
Location: Elsewhere
Posts: 1,595
I think you're correct with HPOS 07 Toni - I normally wait for 07 to avoid the 'step' colour change at right edge...
pmc is offline  
Old 12 October 2009, 23:12   #53
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Quote:
Originally Posted by Toni Wilen View Post
Except it isn't outside of right edge, far from it..

You need to wait for next line's hpos 3 or 7 (I forgot again) or you will see color change on far right border (real A500 + 1081-style monitor with adjusted width)
I think the selection was made for TVs and may very well come from game copperlists, as "nobody" could afford a £299 monitor after buying the £399 computer when the A500 came.

My TVs displayed 320x256 as "right-adjusted in 352 pixels width", and they had limited adjustments. My C1081 revealed buggy scroller charplot routines but was the same resolution from factory. At last you could center the picture properly!

There's some information in the max overscan thread how many pixels are visible on C1081 after being ...adjusted.
Photon is offline  
Old 13 October 2009, 15:32   #54
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Quote:
Originally Posted by Photon View Post
I think the selection was made for TVs and may very well come from game copperlists, as "nobody" could afford a £299 monitor after buying the £399 computer when the A500 came.
Try it first, 0xYYDF FFFE + move to COLOR00 WILL be visible on _ALL_ televisions (very simple reason: hsync is later than hpos=0). Next time test first before replying
Toni Wilen is online now  
Old 13 October 2009, 15:46   #55
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Why would anyone select a horizontal position, set background color, and "enjoy" the ugly joint? There are many demos with this "effect" - do you really think they saw it? Do you really think they saw buggy scroller-charplots outside $d8?

If it wasn't clear, I was talking about how much of the overscan was shown on a TV then. Maybe from $2c to $d2 (estimate).

Maybe I'm missing something, because I don't catch your drift Toni We've already established why $07 or something is a correct wait.
Photon is offline  
Old 13 October 2009, 15:53   #56
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Quote:
I think it was chosen early on as "the first position outside the right edge of a normal screen" where you could change COLOR00, bitplane-pointers,modulo etc without it showing
I simply replied that this isn't true. (especially because 0xYYDF is even visible inside "normal screen", check for example Leander)

EDIT: and in NTSC it is even more visible due to not having that extra missed cycle and first Amiga designs were NTSC only. Sorry but you can't win

Last edited by Toni Wilen; 13 October 2009 at 16:03.
Toni Wilen is online now  
Old 13 October 2009, 16:49   #57
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
TV on its way over, tested on my C1081.

Position $df is (by eyesight) 4 lores pixels outside a standard 320x256 display using $38 to $d0. A 352 screen would display extra pixels in the left margin on a standard TV, but (most of) the $d0 to $d8 pixels would go outside the right edge.

If I adjust the C1081 to match the TV adjustment, the "coppershade step" is juuust inside the plastic edge.

This is what I mean by the $df step being visible or invisible. Outside or inside the right edge. Leander has no $df steps.

I think TVs had a physical black "mask" also to cover up even more, I will know tomorrow.
Photon is offline  
Old 22 December 2009, 16:00   #58
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Finally new undocumented feature, there is real undocumented functional difference between OCS and ECS Denise.

DIWSTRT hpos value zero or one: OCS Denise detects this and enables horizontal display window. ECS Denise ignores it (previous horizontal state remains), only 2 and larger work.

I think this is "cheap" ECS Denise bug fix because there is also some kind of OCS Denise bug/feature: if vertical display window is already enabled (DIWSTRT vpos already matched in earlier lines) and DIWSTRT vertical position matches again in later lines (for example was changed with copper) and DIWSTRT hpos value is zero or one: vertical display window state changes to some kind of frozen state and display gets blanked until next frame.

For example TSP demo disk 2 (Hulkamania) and Majic 12 - Ray of Hope 2 have blank screens if using ECS Denise.

Then there is Kefrens Megademo 8 (snake in Snake Bite part partially remains on screen when ending the part), which works with both Denise versions: OCS Denise because of "frozen state" feature and ECS Denise because hpos=0 gets ignored. This is perfect example of "only working accidentally"
Toni Wilen is online now  
Old 22 December 2009, 18:08   #59
yaqube
Registered User
 
Join Date: Mar 2008
Location: Poland
Posts: 158
This is because horizontal counter inside Denise counts from 2 to 455 (short PAL line). It never is equal to 0 or 1. It seems that the ECS Denise uses an SR flip-flop with "equal" comparators to set or reset horizontal display window while its OCS counterpart uses two "less-greater" comparators which constantly compare the horizontal position value against hpos values in DIWSTART and DIWSTOP registers.

If you try to read VHPOSR register in Agnus you can't read values 4, 6, 8, 10. It means the refresh slots are allocated to these positions.

As Tony has already discovered the vpos counter doesn't change when hpos counter rolls over. It happens a little bit later. Consequently Copper's WAIT xx01 and WAIT xx03 have the same timing.

As the only mean of resetting Denise's hpos counter (or rather setting it to 2) is a write of STRHOR, STRLONG or STREQU registers during the first refresh slot it's obvious that the hpos counters in Denise and Agnus are not in sync. I guess the one in Agnus is advanced by 4. The attached picture illustrates my guesses.

There is no vertical part of DIWSTRT/DIWSTOP registers inside Denise. The vertical blanking is done by writing appropriate strobe register during refresh slots.

Another undocumented feature:

Bits 15-8 of register $07C (LISAID) on AGA machines are loaded from an external shift register. The six most significant bits can be configured by jumpers (at least on an A4000) while bits 9 and 8 are hardwired to GND. These two bits are read by V39+ graphics library during activation of AGA display modes (initiated by SetPatch) and copied after negation to MemType field of graphics library base. If they are not zero the AGA display modes are not enabled although an AGA Lisa id is present in the low byte. An ECS Denise returns all ones in the high byte of $07C register, the default value on AGA machines is $FC but WinUAE always returns $00.
Attached Thumbnails
Click image for larger version

Name:	hpos.jpg
Views:	496
Size:	59.3 KB
ID:	23707  
yaqube is offline  
Old 22 December 2009, 19:29   #60
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,023
Quote:
Originally Posted by yaqube View Post
This is because horizontal counter inside Denise counts from 2 to 455 (short PAL line). It never is equal to 0 or 1.
I thought Denise hpos range (standard PAL) is 0 to 227.5 * 2 = 455.

Unfortunately it is practically impossible to confirm without knowing internals of the chip

Quote:
There is no vertical part of DIWSTRT/DIWSTOP registers inside Denise. The vertical blanking is done by writing appropriate strobe register during refresh slots.
I knew this but as usual I forgot, thanks for reminding

Perhaps old Denise gets confused when strobe and diwstrt hpos are too close together?

Quote:
Another undocumented feature:
This is (partially) documented in aga.guide. "Only" unknown was serial shift register connection.

Confirmed, A1200 returns 0x00F8, ECS Denise 0xFFFC (was 0x00FC in UAE)
Toni Wilen is online now  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
who can provide hardware to create ADFs of some old rare stuff like Nautilus...? Bernd support.Other 3 20 August 2011 00:41
Stuff for sale amiga a1200 plus more retro stuff blast MarketPlace 23 22 June 2010 20:05
Action Replay Undocumented Features deicidal support.Hardware 0 01 March 2010 18:15
I've got some Amiga stuff...I want your SNES stuff! Fingerlickin_B MarketPlace 14 20 February 2009 02:33
Amiga stuff for trade for Atari Stuff 8bitguy1 MarketPlace 0 12 February 2009 06:36

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 20:54.


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