English Amiga Board


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

 
 
Thread Tools
Old 22 August 2020, 16:13   #21
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,072
Quote:
Originally Posted by jotd View Post
well if the code is running in chipmem and if you enable blitter nasty I guess you don't even have to loopwait. Enable it, wait just enough so the blitter understands that it can steal all cpu and disable it again.
Only if blit has no idle cycles. It is also (at least in my opinion) too unsafe, depends on officially undocumented feature, and non-future proof. (for example if some reimplementation has wider/separate chip bus for DMA and CPU)
Toni Wilen is offline  
Old 22 August 2020, 17:23   #22
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,391
Agreed! I'm not going to perform blitwait like that for the sole reason that if I want a game to be fast, I'll do my best to relocate the code in fastmem instead.
jotd is offline  
Old 03 September 2020, 10:27   #23
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,801
It's possible to recognize via code 8361 vs 8370 Agnus (or 8367 vs 8371)?
(in VPOSR there is only a bit for NTSC vs PAL version..)
ross is offline  
Old 03 September 2020, 11:25   #24
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,072
Quote:
Originally Posted by ross View Post
It's possible to recognize via code 8361 vs 8370 Agnus (or 8367 vs 8371)?
(in VPOSR there is only a bit for NTSC vs PAL version..)
Yes. A1000 Agnus variants generate vblank (vblank strobe register access) when vertical position is 1 (instead of correct zero). For example poll INTREQR vblank bit and when it gets set, check vertical position.
Toni Wilen is offline  
Old 03 September 2020, 12:14   #25
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,801
Quote:
Originally Posted by Toni Wilen View Post
Yes. A1000 Agnus variants generate vblank (vblank strobe register access) when vertical position is 1 (instead of correct zero). For example poll INTREQR vblank bit and when it gets set, check vertical position.
Thanks
ross is offline  
Old 03 September 2020, 17:35   #26
Tomislav
Registered User

 
Join Date: Aug 2014
Location: Zagreb / Croatia
Posts: 232
AROS WaitBlit()
Code:
#include "aros/m68k/asm.h"

	.text
	.balign 4
	.globl	AROS_SLIB_ENTRY(WaitBlit,Graphics,38)

AROS_SLIB_ENTRY(WaitBlit,Graphics,38):
    /* Blitter nasty set? Also simultaneous original DIP Agnus bug workaround. */
    btst #2,0xdff002
    bne.s w1

    /* Already finished? Exit immediately. */
    btst #6,0xdff002
    beq.s w0

    /* Set blitter nasty temporarily. */
    move.w #0x8400,0xdff096
w2: /* Keep CPU out of the chipbus for few cycles. */
    tst.b 0xbfe001
    btst #6,0xdff002
    bne.s w2
    /* Clear blitter nasty. */
    move.w #0x0400,0xdff096

w0: rts

    /* Blitter nasty was already set, normal wait loop. */
w1: btst #6,0xdff002
    beq.s w0
    /* Keep CPU out of the chipbus for few cycles. */
    tst.b 0xbfe001
    bra.s w1
Tomislav is offline  
Old 03 September 2020, 18:01   #27
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,801
Quote:
Originally Posted by Tomislav View Post
AROS WaitBlit()
I think the AROS code is redundant.

My version is:
Code:
    /* Set blitter nasty temporarily and keep CPU out of the chipbus
       (fix first A1000 Agnus bug */

       move.w #0x8400,0xdff096

bw:    btst #6,0xdff002
       bne.s bw
 
   /* Clear blitter nasty and keep CPU out of the chipbus
       (fix second pre-ECS Agnus bug) */

       move.w #0x0400,0xdff096
no idea if the
tst.b 0xbfe001
helps a bit on high spec processors
ross is offline  
Old 03 September 2020, 21:14   #28
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,391
There are at least 2 games I know that use this incorrect blitwait

Code:
bw:    btst #6,0xdff002
       bne.s bw
The games are Crazy Cars III and Highway Hawks.

A confirmed A4000 user told me that after fixing the blitwait code to

Code:
    btst #6,0xdff002
bw:    btst #6,0xdff002
       bne.s bw
the graphical errors were gone on Highway Hawks (and no more complains on Crazy Cars III either). So I suppose that there are more machines with this blitter issues than the old Amiga 1000
jotd is offline  
Old 04 September 2020, 11:10   #29
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 580
Quote:
Originally Posted by jotd View Post
well if the code is running in chipmem and if you enable blitter nasty I guess you don't even have to loopwait. Enable it, wait just enough so the blitter understands that it can steal all cpu and disable it again.
Many many drawbacks with this flag. Note that the CPU will also no longer be available for interrupts if the blitter nasty flag is on as the autovectors are by default in chip mem. Avoid this flag, it may have unforeseen consequences.
Thomas Richter is offline  
Old 04 September 2020, 12:17   #30
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,072
Quote:
Originally Posted by Thomas Richter View Post
Many many drawbacks with this flag. Note that the CPU will also no longer be available for interrupts if the blitter nasty flag is on as the autovectors are by default in chip mem. Avoid this flag, it may have unforeseen consequences.
Both have drawbacks.

Blitter only takes all DMA slots if used channel combination uses all cycles (no idle cycles). Most combinations have idle cycles.

When combined with idle cycles, if CPU steals blitter's idle cycle (because nasty was not enabled), blitter loses the cycle. With nasty on, both blitter and CPU would have "used" the cycle. This can make noticeably performance difference (which is very important in demos).

And finally, as was recently noticed, A1000 Agnus is broken and in some situations copper blit wait fails to work correctly if nasty is not on.

Please stop looking through system friendly/OS colored classes all the time
Toni Wilen is offline  
Old 04 September 2020, 14:22   #31
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,072
Quote:
Originally Posted by jotd View Post
A confirmed A4000 user told me that after fixing the blitwait code to
I think this is more likely caused by CPU starting the DMACONR read before BLTSIZE write started. Was BLTSIZE immediately before DMACONR read and was it 68060?
Toni Wilen is offline  
Old 06 September 2020, 12:19   #32
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,072
(I still don't understand all the details yet, so "official" undocumented thread post needs to wait)

Almost solved mystery of Copper WAIT with blitter wait enabled sometimes not working and requiring two WAITs. (or even more if A1000)

It only happens if blitter nasty is not enabled. (Prove me wrong if possible!)

Background:

- It seems blitter is "inhibited" when CPU is allowed to steal blitter cycle (Gary /BLISS signal active and Agnus accepting it).
- CPU allowed to steal cycle from blitter logic is very simple. Gary enables /BLISS if CPU request chipset bus access and it has waited for at least 3 cycles. It does not need to be blitter cycle. Blitter does not even need to active.

When CPU writes to BLTSIZE, /BLISS is guaranteed not to be active (because CPU wrote to BLTSIZE which is in chipset bus) and blitter starts normally.

When Copper writes to BLTSIZE, /BLISS might be active at the same time (if CPU has already waited for few cycles due to bitplane or copper DMA). In this case BLTSIZE write still succeeds and blitter starts but it seems busy bit logic is inhibited (these is some latch that needs clocking?) and busy isn't set until inhibited status gets cleared. Unfortunately this can't be tested with CPU because CPU access would clear the "inhibited" state immediately.

Result is that in this situation following copper WAIT with blitter wait enabled might see cleared busy bit.

It is even worse with A1000 because busy bit gets set when blitter gets first DMA slot. This combined with "inhibited" status can mean blitter busy might not be set even if there are 2xWAITs.
Toni Wilen is offline  
Old 06 September 2020, 15:20   #33
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,391
Quote:
I think this is more likely caused by CPU starting the DMACONR read before BLTSIZE write started. Was BLTSIZE immediately before DMACONR read and was it 68060?
it's reportedly 68040. And in both cases, blitwait is not right after BLTSIZE write
jotd is offline  
Old 06 September 2020, 18:15   #34
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 24,072
Quote:
Originally Posted by jotd View Post
it's reportedly 68040. And in both cases, blitwait is not right after BLTSIZE write
Hmm... I still can't believe it is DMACONR related but some weird 68040 board "feature". Do you have the previous slave that has the problem? I'd like to take a closer look.
Toni Wilen is offline  
Old 15 September 2020, 21:23   #35
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 729
Many years ago I had problems with the initial decryption routine in Arkanoid. It uses the blitter with all channels and max bltsize. With nasty enabled I had reports that on some machines the machine locked up and required reset.
Maybe also a hardware problem but I try to avoid nasty where possible.
Wepl is offline  
Old 16 September 2020, 07:48   #36
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,391
Toni I'll zone some installed Highway Hawks game with the old version. Maybe a cracked version would run from floppy on a A4000 but maybe not.
jotd is offline  
Old 16 September 2020, 10:31   #37
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 580
If the problem is with a 68040: Is this configured correctly? The custom chip memory area must, absolutely must be set to cache inhibit serialized. The 68040 has a "push queue" in which it stores outgoing memory calls, and it may delay the execution of this writes until the bus is idle. That is, after a blitter-write instruction, the blitter may not yet have seen this write because it is waiting in the push-queue of the 68040 to be executed. You can place a NOP after the write to ensure that the write is going out.
Thomas Richter is offline  
Old 16 September 2020, 12:23   #38
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,391
it's running under whdload. I hope that whdload does the proper initialization of the custom chips cache. I think that there would be more problems than blits if this area was misconfigured.
jotd is offline  
Old 16 September 2020, 14:08   #39
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,144
Quote:
Originally Posted by jotd View Post
it's running under whdload. I hope that whdload does the proper initialization of the custom chips cache. I think that there would be more problems than blits if this area was misconfigured.
It's the job of the cpu library to set this up, not whdload, but depending on which library is used, maybe it isn't?
hooverphonique is offline  
Old 16 September 2020, 18:29   #40
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 49
Posts: 4,391
whdload takes over the system, including MMU. For instance, each attempt to write in a location that whdload hasn't declared as accessible results in an access fault (example: writing on DEF080 which "works" to set copperlist but it's not the official DFF080 address)
jotd is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Amiga 1200 hardware fixes for Gayle bugs Mick support.Hardware 0 10 November 2019 12:59
Triple buffering, blitter queues and bugs deimos Coders. General 0 03 October 2019 11:25
Blitter settings + amiga hardware ref. Legionary Amiga scene 1 25 September 2016 16:57
Chip's Challenge slowdown due to blitter waits Gaula92 project.WHDLoad 33 10 March 2013 16:43
Lack of blitter waits on A500 Codetapper Coders. Asm / Hardware 3 09 September 2012 13:45

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 01:36.


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