English Amiga Board


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

 
 
Thread Tools
Old 23 October 2020, 14:55   #41
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 216
That's what first/last word mask ($044/$046) is for. Instead of $ffff, you use a different value to mask out whatever is coming in from the previous line.
a/b is offline  
Old 24 October 2020, 02:17   #42
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
I need to show a picture to explain what happens with $FFF0, BLTALWM



Mask is applied yes but the result is also shifted. Masking by the same amount of shifted bit just erases the image. And in any case the initial problem of a missing line is still there.



BTW I checked the AHRM and found the part where this specific problem is addressed:

Quote:
On shifted blits, therefore, we only get zeros shifted in for the first
word of the first row. On all other rows the blitter will shift in the
bits that it shifted out of the previous row. For most graphics
applications, this is undesirable. For this reason, the blitter has the
ability to mask the first and last word of each row coming through the A
DMA channel .
But then changes a bit the subject, not explaining HOW to avoid the problem by applying masks
Attached Thumbnails
Click image for larger version

Name:	087.png
Views:	139
Size:	20.4 KB
ID:	69467  
KONEY is offline  
Old 24 October 2020, 05:59   #43
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 216
You have to do 2 different blits. First you shift the whole thing to the right, then you fill the empty columns on the left with a masked merge of hidden buffer columns/word (now containing whatever was pushed out) on the rigth with the first (now partially empty) word on the left.

Also, if you are doing 4 consecutive blits without changing a single blitter register, you can merge them into a single blit by combining the height, as long as it's 1024 or less (set it to 0 if it's 1024). Assuming OCS chipset.
a/b is offline  
Old 24 October 2020, 10:12   #44
morbid
Registered User

 
Join Date: Aug 2020
Location: Huddinge
Posts: 6
I would do it like this for rol:

- Create a 336px x 256px bitplane

- Setup a 320px x 256px screen

Then for each frame:

- copy the src leftmost column (1 word, 16 pixels, x=0 to 15, height 256) to the dst last column (x=320 to 335, height 256)

- copy the entire bitplane in descending mode with any shift value
morbid is offline  
Old 25 October 2020, 00:33   #45
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
Thanks! I'm almost done following your advice but I'll come later on this because I'm still testing.

However I'm a bit confused about the blitsize thing. After checking http://amigadev.elowar.com/read/ADCD.../node001D.html
I set all first 10 bits to 1 but the scroll is missing 1 final line, and it makes sense because 10 bits=1023 not 1024 -> https://calculator.name/baseconvert/...mal/1111111111

so even the AHRF is wrong? And I'm pretty sure the line is missing.

Also setting all to 0 results in a crash.

Quote:
Originally Posted by a/b View Post
You have to do 2 different blits. [..]
Also, if you are doing 4 consecutive blits without changing a single blitter register, you can merge them into a single blit by combining the height, as long as it's 1024 or less (set it to 0 if it's 1024). Assuming OCS chipset.
KONEY is offline  
Old 25 October 2020, 02:41   #46
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 216
All 16 bits set to 0 or top 10 (blit height) set to 0? All bits set to 0 means max OCS height and max OCS width, so 1024x1024 pixels or 1024x64 words.
Since blitting with 0 width or height doesn't make sense a 0 is used for the "maximum" value, instead of being unused. For example: 1024 height, you need 11 bits to specifiy that and you only have 10 available in the register, so you drop the highest bit and end up with 10 zeroes, hence you use a 0.

Also, first 6 is width (divided by 16, so in 16-bit words), top 10 is height in pixels. First 10 is incorrect, unless it's a typo.
a/b is offline  
Old 26 October 2020, 19:35   #47
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
Yes it was a typo! Also I checked again and I confirm that setting the LAST 10 bits to 0 1024 lines are blitted at once!
KONEY is offline  
Old 26 October 2020, 20:12   #48
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
OK, this is nearly working. I'm not an expert but it looks like a bit of a workaround to me, anyway it's good to make practice.

There's only one problem with precision, In the example I've set a 3px scroll and left unmasked 3px in the patch. These values should match if I understood correctly.

But it seems like the very first column copy is performed before the shift, which makes no sense because it's clearly after and waits are in place. From the picture evidence of these 3 pixel, changing shift + mask to 1 reduces the vertical line to 1 and so on.



https://github.com/KONEY/asm68k-test..._FULL_SCROLL.s

I have no idea why this is happening maybe I'm moving too much data at the same time and this has side effects on timings?

Quote:
Originally Posted by a/b View Post
You have to do 2 different blits. First you shift the whole thing to the right, then you fill the empty columns on the left with a masked merge of hidden buffer columns/word (now containing whatever was pushed out) on the rigth with the first (now partially empty) word on the left.
Attached Thumbnails
Click image for larger version

Name:	088.png
Views:	85
Size:	38.9 KB
ID:	69508  
KONEY is offline  
Old Yesterday, 00:58   #49
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 216
This works for me:
Code:
SPEED		EQU	3

__SCROLL_BG:
	MOVEM.L	D0-A6,-(SP)	; SAVE TO STACK
	MOVE.L	KONEYBG,A4
	BTST.B	#6,DMACONR	; for compatibility
	bsr	WaitBlitter

	MOVE.L	A4,BLTAPTH	; BLTAPT  (fisso alla figura sorgente)
	MOVE.L	A4,BLTDPTH
	MOVE.W	#$FFFF,BLTAFWM	; BLTAFWM lo spiegheremo dopo
	MOVE.W	#~(1<<SPEED-1),BLTALWM	; BLTALWM lo spiegheremo dopo
	MOVE.W	#(SPEED<<12)+%100111110000,BLTCON0
	MOVE.W	#%0000000000000000,BLTCON1	; BLTCON1 BIT 12 DESC MODE
	MOVE.W	#0,BLTAMOD	; BLTAMOD =0 perche` il rettangolo
	MOVE.W	#0,BLTDMOD	; BLTDMOD 40-4=36 il rettangolo

	MOVE.W	#blitsizeF,BLTSIZE	; BLTSIZE (via al blitter !)

	; PATCH FIRST WORD COLUMN
	bsr	WaitBlitter
	moveq	#bpl-2,d0
	MOVE.L	A4,BLTAPTH	; BLTAPT  (fisso alla figura sorgente)
	MOVE.L	A4,BLTDPTH
	add.l	d0,A4
	MOVE.L	A4,BLTBPTH
	MOVE.W	#$FFFF,BLTALWM	; BLTALWM lo spiegheremo dopo
; d = ac+b!c = abc+a!bc+ab!c+!ab!c = %11100100 = $e4
	move.l	#$0de40000,BLTCON0
	MOVE.W	#$ffff>>SPEED,BLTCDAT
	MOVE.W	d0,BLTAMOD
	MOVE.W	d0,BLTBMOD
	MOVE.W	d0,BLTDMOD

	MOVE.W	#%0000000000000001,BLTSIZE	; BLTSIZE (via al blitter !)

	MOVEM.L	(SP)+,D0-A6	; FETCH FROM STACK
	RTS
a/b is offline  
Old Yesterday, 02:05   #50
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
I need to study this code, but there are some syntaxes new to me like: #~(1<<SPEED-1), what it is it for?
KONEY is offline  
Old Yesterday, 02:19   #51
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 216
To dynamically calculate masks, based on SPEED.
%0000000000000001 1
%0000000000001000 1<<3 left-shift
%0000000000000111 1<<3-1
%1111111111111000 ~(1<<3-1) bitwise not
a/b is offline  
Old Yesterday, 09:00   #52
morbid
Registered User

 
Join Date: Aug 2020
Location: Huddinge
Posts: 6
I would do the blits in the opposite order.
This requires the bitplane to be one column wider than the screen.

First copy the column that will be shifted out (without shifts), and then shift the entire bitplane.

I would use a mask of $ffffffff and just do a copy from A to D for both blits, making sure that the first blits dst column is outside of the visible area of the screen to hide any glitches.
morbid is offline  
Old Yesterday, 15:31   #53
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,890
@a/b You left italians' comments!
sandruzzo is offline  
Old Yesterday, 16:35   #54
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
It is already wider,

this should work but what benefit would introduce compared to the other order? not needing to mask when patching?

Quote:
Originally Posted by morbid View Post
I would do the blits in the opposite order.
This requires the bitplane to be one column wider than the screen.
First copy the column that will be shifted out (without shifts), and then shift the entire bitplane.
I would use a mask of $ffffffff and just do a copy from A to D for both blits, making sure that the first blits dst column is outside of the visible area of the screen to hide any glitches.
KONEY is offline  
Old Yesterday, 18:39   #55
morbid
Registered User

 
Join Date: Aug 2020
Location: Huddinge
Posts: 6
Speed.
And also for me it is less complex.
morbid is offline  
Old Yesterday, 21:04   #56
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
Quote:
Originally Posted by a/b View Post
This works for me:
YEs it works! thanks!

I need to fully understand what was wrong on my code, so as far I understand you:

moved the masking in the first blit
changed minterms in the second
added something in BLTCDAT which is new to me but I'll check the AHRM
used a data register to load the needed offset in A4 (this looks like a coding style and shouldn't introduce changes in the result)

anything else? (apart from dynamic speed)
KONEY is offline  
Old Today, 00:29   #57
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 46
Posts: 464
More after examining deeper a/b's code:

Masking is still on second blit but is performed using a disabled C channel as a source instead of using BLTA*WM.
This MOVE.W #~(1<<SPEED-1),BLTALWM in first blit has no effect and can be replaced with a "standard" #$FFFF

Still not sure what was wrong with my code, but now I'm too busy with next step: DESC MODE
KONEY is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Blitter shift BACKWARDS KONEY Coders. Asm / Hardware 3 29 January 2020 22:50
My 360 controller eats USB cords? BullyDog OT - Gaming 10 27 July 2018 01:54
Blitter Mask shift during copy LeCaravage Coders. Asm / Hardware 6 18 March 2018 23:50
Mounting real CF eats up a lot of RAM Akira support.WinUAE 84 10 July 2016 21:26
mapROM eats too much RAM alphonsus support.Hardware 9 10 July 2008 02:16

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 02:06.


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