English Amiga Board


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

 
 
Thread Tools
Old 11 April 2017, 21:31   #21
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 47
Posts: 811
Quote:
Originally Posted by Wrangler View Post
@ross: Hi - just tested both of those adfs on a real A500 (OCS) and they both work fine, no glitches.
Thanks!

Bye,
ross
ross is offline  
AdSense AdSense  
Old 19 April 2017, 18:17   #22
losso
Registered User

losso's Avatar
 
Join Date: Oct 2013
Location: Hamburg
Posts: 44
Same on ECS Agnus here with ross' versions.

I have started to build a minimal example to reproduce this and tried to rule out other factors one-by-one: the copperlist was unbuffered, waiting until mid-screen before the blit queue, double-checking interrupt handler, check if I introduced a bug into the framework etc. -- so far with no success.

Since I have brought back some other fails-on-hardware bugs to fix from Revision (probably unrelated, though), it might take some time until I can get back to this.

Thanks for all your efforts on pinning this down so far!
losso is offline  
Old 20 April 2017, 08:47   #23
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 490
Quote:
Originally Posted by losso View Post
Same on ECS Agnus here with ross' versions.

I have started to build a minimal example to reproduce this and tried to rule out other factors one-by-one: the copperlist was unbuffered, waiting until mid-screen before the blit queue, double-checking interrupt handler, check if I introduced a bug into the framework etc. -- so far with no success.

Since I have brought back some other fails-on-hardware bugs to fix from Revision (probably unrelated, though), it might take some time until I can get back to this.

Thanks for all your efforts on pinning this down so far!
I've just fixed some nasty fails on real hardware bugs in a game I'm working on. Maybe we should start a thread to document the pitfalls as we find them to help people avoid our mistakes in the future.
alpine9000 is offline  
Old 20 April 2017, 09:31   #24
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 47
Posts: 811
Quote:
Originally Posted by alpine9000 View Post
I've just fixed some nasty fails on real hardware bugs in a game I'm working on. Maybe we should start a thread to document the pitfalls as we find them to help people avoid our mistakes in the future.
Take me as interested
ross is offline  
Old 20 April 2017, 10:09   #25
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
Only if test program exists that confirms it. It must not be some boring theory without proof (seen those too many times..) or "just to be safe, do this"
Toni Wilen is online now  
Old 20 April 2017, 11:19   #26
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 490
Quote:
Originally Posted by Toni Wilen View Post
Only if test program exists that confirms it. It must not be some boring theory without proof (seen those too many times..) or "just to be safe, do this"
I'm my case they were just bugs that for whatever reason didnt manifest ever under emulation.

For example I was poking the bitplane pointers in a copper list in a non synchronised way which I'm guessing meant that every now and then on real hardware left them in an invalid state when they were latched?

Timing on real hardware was everything, an unrelated change would change the timing and mask the bug.

In the end I disabled th copper DMA before patching and that seemed to fix it.
alpine9000 is offline  
Old 20 April 2017, 11:28   #27
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
You probably hit the chipset feature where write to DMA pointer register does nothing if next cycle is same DMA channel's data read/write cycle. (Most emulation modes do not emulate this because wrong CPU timing, especially if not 68000, can break situations which work in real hardware)

This is why real world test case is needed. To find and confirm the exact root cause and to test if it is hardware revision specific.
Toni Wilen is online now  
Old 20 April 2017, 11:33   #28
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 490
Quote:
Originally Posted by Toni Wilen View Post
You probably hit the chipset feature where write to DMA pointer register does nothing if next cycle is same DMA channel's data read/write cycle. (Most emulation modes do not emulate this because wrong CPU timing, especially if not 68000, can break situations which work in real hardware)

This is why real world test case is needed. To find and confirm the exact root cause and to test if it is hardware revision specific.
I can try and check out an old version of my game that had this bug. Problem is, the bad effect was very intermittent, but I was able to reproduce it on an a500 and a1200.

I had a blitter issue that was 100% reproducible on real hardware and perfect under emulation so I can try and resurrect that if you're interested.
alpine9000 is offline  
Old 20 April 2017, 13:40   #29
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
Quote:
Originally Posted by alpine9000 View Post
I can try and check out an old version of my game that had this bug. Problem is, the bad effect was very intermittent, but I was able to reproduce it on an a500 and a1200.
These are annoying but if it happens in real a500: try to create simple test case (does not need to be really simple but all "useless extra" removed)

Quote:
I had a blitter issue that was 100% reproducible on real hardware and perfect under emulation so I can try and resurrect that if you're interested.
Yes please, this is the only way to document and emulate these properly. (Unless it is writing to BLTCON0/1 after blitter has been started..)
Toni Wilen is online now  
Old 21 April 2017, 09:25   #30
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 490
Quote:
Originally Posted by Toni Wilen View Post
These are annoying but if it happens in real a500: try to create simple test case (does not need to be really simple but all "useless extra" removed)



Yes please, this is the only way to document and emulate these properly. (Unless it is writing to BLTCON0/1 after blitter has been started..)
I emailed you the buggy version of the game.
alpine9000 is offline  
Old 23 April 2017, 15:00   #31
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
Quote:
Originally Posted by alpine9000 View Post
I had a blitter issue that was 100% reproducible on real hardware and perfect under emulation so I can try and resurrect that if you're interested.
Fixed.

Blitter ADAT and BDAT (BDAT in this program) writes in non-DMA mode didn't shift in old value (if shift was non-zero). Old data from last blit corrupted the font writer's mask data. No corruption if old data was zero.

Previous blit used B-channel, next blit had B-channel disabled but it was part of used minterm, BLTBDAT was properly set by CPU write but if shift was non-zero, old data was shifted in to final "B hold" value.

It seems "old" data ("A old" and "B old" in HRM) is automatically cleared only if channel is enabled when writing to BLTSIZE.

EDIT: Only B channel "remembers" old value. "A old" is always cleared.

Last edited by Toni Wilen; 24 April 2017 at 17:52.
Toni Wilen is online now  
Old 27 January 2018, 17:41   #32
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,503
There are multiple separate issues here. But I could address some questions about loading the Blitter registers correctly.

1. Blitwait must be before every blit. Only if you need to rely on the result of the blit for the CPU, or if you plan to disable Blitter DMA, should you wait after the blit. Examples: bob collision detection (BZERO) or joint rendering into the same buffer (BLTDPTx) by the blitter and the CPU.

2. To support early A1000 Blitter chips, the documentation says to read twice before the CPU can rely on the value. Copper blits need only to perform one blit wait and nothing else. Blitter interrupts are triggered by BBUSY and so need no wait.

3. Register load order: There are only 4 important registers: BLTCONx, BLTxDAT, BLTAxWM, and BLTSIZE. This is the normal load order, all other registers can be set in any order after this. BLTSIZE starts the blit and obviously should be last.

BLTxDAT will be shifted immediately upon the write to the corresponding BLTCONx, do this instead if that's what you desire.

BLTADAT must be set before BLTAxWM for BLTADAT to be masked.
Photon is offline  
Old 27 January 2018, 17:53   #33
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
Quote:
Originally Posted by Photon View Post
BLTxDAT will be shifted immediately upon the write to the corresponding BLTCONx, do this instead if that's what you desire.

BLTADAT must be set before BLTAxWM for BLTADAT to be masked.
No. HRM is wrong, it is probably (too) simplified explanation.

BLTADAT does not shift immediately or mask immediately. Only BDAT does immediate shifting. It most likely does not work like BDAT because mask is dynamic, first and last word mask is different than middle words and shifting is done after masking.
Toni Wilen is online now  
Old 27 January 2018, 20:22   #34
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,503
Hm, sorry for muddling matters by replying in the Undocumented Hardware Features thread at about the same time.

I just took the general meaning of the problems and replies in this thread and wanted to minimize confusion. These are just the simplest rules I've found that lets a coder write or debug a blit routine and be sure that it's correct. (There's a short article on Coppershade, but it's not as simplified.)
Photon is offline  
Old 27 January 2018, 20:32   #35
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
Yeah but this thread is not beginner stuff so everything should be 100% accurate
Toni Wilen is online now  
Old 27 January 2018, 22:39   #36
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,503
I have to disagree. I'm addressing intent, and you're addressing hardware implementation/emulation accuracy. Two sides of the same coin, yet worlds apart. Ends of a spectrum.

The chips stay the same and do what you tell them, so it's about 100000 times more likely (rough estimate) that the coders are writing code that doesn't express their intent.

HRM is certainly accurate and complete enough to allow a relatively experienced hardware programmer (whether new to Amiga or not) to code a Copper list that blits, and a font writer is beginner stuff and the code worked and you fixed the emulation.

I have to wag my finger and say "tsk, tsk!" at that you say you don't like "better do this just to be safe", but then suggest changing the order of register writes for no good reason and haven't protested against "try this" things such as waiting an extra line, double blit waits in Copper lists, etc. (Which I'm quick to do now! )

I normally refuse to help if no code is posted, but I still wanted to help.

Now I used my rules and they ruled out the blits, and on the HRM page I linked it says that the blitter WAIT is a normal WAIT with an AND condition provided by bit 15. HPOS below $07 as you know is on the previous line and will fail >= comparisons on the raster.

$0001,$0000 is not a correct WAIT instruction, and $0007,$7ffe is a correct Copper Blit WAIT.
Photon is offline  
Old 28 January 2018, 01:36   #37
ross
Omnia fert aetas

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 47
Posts: 811
Quote:
Originally Posted by Photon View Post
$0001,$0000 is not a correct WAIT instruction, and $0007,$7ffe is a correct Copper Blit WAIT.
Well, technically $0001,$0000 is a valid WAIT instruction that.. do not wait beam position but blitter
Actually $0001,$8000 can be used to make delay of exactly 6CCK in copper list (like $01fe,$0000 for 4CCK).
Call them if you want CNOP6 and CNOP4.

Last edited by ross; 28 January 2018 at 09:39. Reason: clarifications
ross is offline  
Old 28 January 2018, 09:26   #38
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,080
Quote:
Originally Posted by Photon View Post
I have to disagree. I'm addressing intent, and you're addressing hardware implementation/emulation accuracy. Two sides of the same coin, yet worlds apart. Ends of a spectrum.
Perhaps..

I always want everyone (not just me) to also know exactly WHY something happens when I do this and that instead of blindly following some guides or HRM and possibly even refusing to attempt something crazy which hopefully does something unexpected, then it is time to try to find out why.

Demo coders are supposed to make crazy things
Toni Wilen is online now  
Old 28 January 2018, 15:14   #39
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,503
So now they can do crazy things with a correct blit wait that doesn't waste a scanline per blit.
Photon is offline  
Old 02 February 2018, 08:24   #40
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 130
Quote:
Originally Posted by Photon View Post
2. To support early A1000 Blitter chips, the documentation says to read twice before the CPU can rely on the value. Copper blits need only to perform one blit wait and nothing else. Blitter interrupts are triggered by BBUSY and so need no wait.
Are you really sure this only applies to the CPU? What happens, if we've got a lores display with 5 or 6 planes or a hires display with 3 or 4 planes and additionally all sprite channels are used? It would not make sense, if the blitter on the A1000 would always catch the first memory cycle, because bitplane DMA has always priority over the copper and the blitter in that order. The copper also needs in these cases two $0001,$0000 waitblits to be sure that the blitter is finished.

@Toni: Could you confirm this behaviour for these cases on the A1000?

Last edited by dissident; 04 February 2018 at 04:57.
dissident 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
2 questions: Not used DFFxxx location Copper behavior and Indivision ECS registers pandy71 Coders. Asm / Hardware 2 13 January 2015 14:13
Strange bitmap behavior losso support.WinUAE 2 31 December 2013 12:42
Very strange SFS behavior. Thorham support.Apps 26 17 October 2009 15:04
discovered strange behavior NfernalNfluence support.WinUAE 7 26 May 2009 08:10
Strange behavior in A4000 Computolio support.Hardware 8 22 September 2007 12:39

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:30.


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