English Amiga Board


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

 
 
Thread Tools
Old 24 December 2019, 02:24   #1
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
Copper instructions

So I read this thread http://eab.abime.net/showthread.php?t=21866 and it's basically the same information that is also written in my book (Data Becker Intern), but I don't really understand why my copperlist works now.


According to those sources, the MOVE instruction takes
0: Set to 0
8-1: Register destination address.


So to my understanding, if I want to set the Color00 value the register is $180, and the value is black. I would expect that the copperlist should look like this:


dc.w $0180<<1, $0000


But this doesn't work, instead I have to write


dc.w $0180, $0000


Why?
sparhawk is offline  
Old 24 December 2019, 02:59   #2
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,608
It's luckily not that complicated. Bit zero of the first and second word of Copper instructions simply select which instruction you wish the Copper to execute.

Code:
        WORD 1   WORD 2
MOVE    BIT 0=0  BIT 0=? (depends on value to move, has no meaning for selecting instruction)
WAIT    BIT 0=1  BIT 0=0
SKIP    BIT 0=1  BIT 0=1
Then, you simply OR (not shift) the bits above with the content of the instruction. For WAIT & SKIP this is the location to wait for and how to wait, for MOVE this is the address of the register and the value to write.

Since all Amiga custom chipset registers are even addresses, bit 0 of the register will always be 0, so all MOVE commands will have bit 0 set to 0.
roondar is offline  
Old 24 December 2019, 12:03   #3
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
Yeah, that's how I understood it. But then the documentation is wrong, right? Because it's bit 0-8 with bit 0 always 0, as you said.

IMO it's a different meaning if the documentation says

Bit 0 selects the mode (WAIT/MOVE) and Bit 1-8 is the target register

or

WAIT selects the register with Bit 0-8 with Bit 0 always set to 0.

The first meaning I would interpret as, the register can have a value from 0-255 but must be left shifted by one, while the second I would interpret as: The register can have a value between 0 and $1FE (which is indeed the case) but with bit 0 cleared.

I can't check how it is written in the Hardware RKRM as I only get my copy tonight.
sparhawk is offline  
Old 24 December 2019, 12:40   #4
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by sparhawk View Post
Yeah, that's how I understood it. But then the documentation is wrong, right? Because it's bit 0-8 with bit 0 always 0, as you said.

IMO it's a different meaning if the documentation says

Bit 0 selects the mode (WAIT/MOVE) and Bit 1-8 is the target register

or

WAIT selects the register with Bit 0-8 with Bit 0 always set to 0.

The first meaning I would interpret as, the register can have a value from 0-255 but must be left shifted by one, while the second I would interpret as: The register can have a value between 0 and $1FE (which is indeed the case) but with bit 0 cleared.

I can't check how it is written in the Hardware RKRM as I only get my copy tonight.
When you get to check, you'll find the language in the manual easy to misinterpret:

Quote:
FIRST INSTRUCTION WORD (IR1)
Bit 0 Always set to 0.
Bits 8 - 1 Register destination address (DA8-1).
Bits 15 - 9 Not used, but should be set to 0.
This is how I think of it:

If there's a legal register address in the first word, then it's a move. By legal, I mean even, therefore bit 0 should be 0. The whole of the word is the register address, i.e. 0x0180.

If the first word is an odd number, therefore bit 0 is 1, then it's either a wait or a skip, and you then need to look in word 2 to work out which.

I think it's explained in the way it is because those bit 0s are really used to interpret the command. They don't have a "real" value, you just have to know that the missing bit gets inserted behind the scenes.
deimos is offline  
Old 26 December 2019, 18:32   #5
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
So I'm doing some very simple animation using the copper. Just two colors and the it should scroll down. So far this works, but I have some strange effect in the middle of it:
The copperline starts at $2c and on each iteration it is increased by 1 until it reaches $ff (haven't figured out yet how to create a copper line below 256).
This works fine so far until I reach $78. When I increase it to $79 there is suddenly a "jump" where the line is not one pixel below, but a lot. Don't know how much it suddenly increases, but you can see it on the attached screenshot.

Now when I keep increasing the value, it's stuck at this line until at some point it suddenly start to move again pixel by pixel as it should. I assume that this gap where it appears to be stuck, is exactly the amount of the "jump".
Attached Thumbnails
Click image for larger version

Name:	SCR-120.jpg
Views:	41
Size:	80.8 KB
ID:	65670  
sparhawk is offline  
Old 26 December 2019, 19:01   #6
deimos
Registered User

 
Join Date: Jul 2018
Location: France
Posts: 537
Quote:
Originally Posted by sparhawk View Post
So I'm doing some very simple animation using the copper. Just two colors and the it should scroll down. So far this works, but I have some strange effect in the middle of it:
The copperline starts at $2c and on each iteration it is increased by 1 until it reaches $ff (haven't figured out yet how to create a copper line below 256).
This works fine so far until I reach $78. When I increase it to $79 there is suddenly a "jump" where the line is not one pixel below, but a lot. Don't know how much it suddenly increases, but you can see it on the attached screenshot.

Now when I keep increasing the value, it's stuck at this line until at some point it suddenly start to move again pixel by pixel as it should. I assume that this gap where it appears to be stuck, is exactly the amount of the "jump".
There are 8 bits of value to wait for, but only 7 bits of mask - what should be the highest mask bit is used for waiting for the blitter to finish instead. You have to jump through some hoops.
deimos is offline  
Old 26 December 2019, 19:33   #7
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,425
No, this cannot be the reason, the bit7 for the y position is always masked (because used for the BFD bit in WAIT instruction).

If you post the exe we can find the problem, that's probably a bug in code
ross is offline  
Old 26 December 2019, 20:06   #8
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
I attached the binary. Source code can be found here: https://github.com/skeetor/amiga-utils/tree/develop in projects/SimpleCopperAnim project.

If you change the initial vlaue of the copperlist to i.E. $3001 instead of $7801 you can see that it goes down one by one.

Pressing Left Mouse exits, Right Mouse increases the value by one.

I have still to look into the bits that demios mentioned. As I understood him, it may be that there is the problem. Guess I have to read the docas again for it.

Actualy the line should scroll down until it hits the bottom of the screen, but as I said I have yet to figure out how to go beyond 256 lines with the copper, so it stops ate (NTSC?) screenline.
Attached Files
File Type: zip SimpleCopperAnim.zip (1.2 KB, 9 views)

Last edited by sparhawk; 26 December 2019 at 21:06.
sparhawk is offline  
Old 26 December 2019, 20:42   #9
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,425
Quote:
Originally Posted by sparhawk View Post
I attached the binary.
Where can I find it?

Quote:
I have still to look into the bits that demios mentioned. As I understood him, it may be that there is the problem. Guess I have to read the docas again for it.
Problem here is not the BFD bit.
But we need the executable for certainty, a bug in the code could create side effects of all kinds ..

Quote:
, but as I said I have yet to figure out how to go beyond 256 lines with the copper, so it stops ate (NTSC?) screenline.
Wait a position at end of $ff line (like dc.w $ffdf,$fffe), then redo the wait on successive lines (which are now from $100 onwards counting from $00).
ross is offline  
Old 26 December 2019, 21:10   #10
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
Ups! I didn't notice that I can't attach files with .exe Now I attached itas zip in the original file.


Quote:
Originally Posted by ross View Post

Wait a position at end of $ff line (like dc.w $ffdf,$fffe), then redo the wait on successive lines (which are now from $100 onwards counting from $00).

Yes, that's what I found in the docs, but haven't looked into yet, because of the strange line $78 behavior.

Not yet fully clear to me how exactly should implement this rewait, but that's part of the fun to find out.
sparhawk is offline  
Old 26 December 2019, 21:24   #11
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,425
Quote:
Originally Posted by sparhawk View Post
Ups! I didn't notice that I can't attach files with .exe Now I attached itas zip in the original file.
Works for me.. no jump from $78 to $79.
ross is offline  
Old 26 December 2019, 21:44   #12
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
So the black bar goes down one line? Strange. I'm running WinUAE Beta 10, and I also compiled the latest source from git as well as the Original download from the website 4.2.1 and all show the same as I have been showing in the screenshot.

I just tested it with a new plain WinUAE config and there it works as well, so it seems a bug in WinUAE with some setting?

I attach my config, but I will look into this and see if I can find the option that causes it.
Attached Files
File Type: uae config_dev_hd.uae (12.3 KB, 7 views)
sparhawk is offline  
Old 26 December 2019, 21:48   #13
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,635
Works for me too... no issues with $78 to $79
mcgeezer is offline  
Old 26 December 2019, 23:03   #14
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
Strange! I created a WB1.3 config from disk and DH0 and both work. When I boot my Devpac DH0 environment the same binary does not work anymore. I attached my DH0 setup and the config I load it with.

1. Boot
2. Start Shell
3. cd projects
4. copperanim
5. Right Click Mouse (the jump should show on first click but I once had to click again).

When I tested it with different configurations I had once the situation where it suddenly happened with $79/$80 instead.

It definitely seems to be something in the confguration. I now took the config I created with a standard WB1.3 on DH0: which works, and pointed it to my DevPAC DH0 environment from above. And this works as well, so it's not the Devpac environment.
Attached Files
File Type: zip Develop.zip (1.30 MB, 8 views)
File Type: uae config_dev.uae (12.3 KB, 6 views)

Last edited by sparhawk; 26 December 2019 at 23:16.
sparhawk is offline  
Old 26 December 2019, 23:25   #15
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
I finally found the problem.

It's this option in the config:

Code:
gfx_filter_autoscale=scale
When I comment this line, it works as expected. I'll I post a bug report to Toni.
sparhawk is offline  
Old 27 December 2019, 00:21   #16
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
Yeah, scaling filter can be evil. Maybe it's not a bug, but working as intended... Check with Toni in any case.
A while ago I had a similar problem: http://eab.abime.net/showthread.php?t=97161
Basically, filter will stretch your screen because it ends 'prematurely'.
a/b is offline  
Old 27 December 2019, 00:42   #17
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
I think the behavior is quite confusing and I don't see what the intended design is. Form the name and seeing how it behaves, I would expect that this option resizes the display to fit the aspect ratio in the current window. So I can see that a black border is added on the left and right. However, this doesn't seem to be the case on the top and bottom. I could understand it, if there is some border added at the top to account for a non-fitting size, but after I changed the color to blue, I can see that this is not the case. And it's not really easy to understand why the scanline PX should be at position SX while PX+1 is suddenly at SX+30 (or so), without changing the host window size.
sparhawk is offline  
Old 27 December 2019, 02:18   #18
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,608
It would all depend on the algorithm used for scaling. Scaling is much harder than it looks for Amiga screens, considering the vast number of different screen sizes used in programs. You're pretty much stuck with scaling the entire display area, which almost never neatly fits scales to the resolution used by the end user. It's bound to distort.

I try to avoid non-integer scaling in WinUAE when developing. I usually use a windowed mode running at 2x size. But then, I do mostly use vasm/vlink on the PC for building so I don't have to edit my source on the virtual Amiga. If I had to, I'd probably use a full screen mode but still try to use a form of integer scaling.

Anyway, it's not the Copper that's at fault here or your code. So that's good
roondar is offline  
Old 27 December 2019, 08:18   #19
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
I haven't looked at the code and I'm sure that the emulator is really a complex beast. But considering the visible behavior, I still think that this is a bug on the emulator.
This demo is really simple. There are no special tricks involved, and the copper list is as simple as it can get.

1. Set color 0 to Blue
2- Wait for scanline 120
3. Set color 0 to Red.
4. END

On each Right Mouse click the scanline is increased by one.

That's about it.

If no scaling is active, you can see on each click, that the color moves down line by line. If scaling is active, and NO other parameter is changed (no host window resize or anything else), the same behavior is shown until some arbitrary line is reached. At this point the scanline is suddenly increased by 20 (or something) instead of the one. And additionally continuing to increase it by one, suddenly does no longer move the color down, instead it stays in place, until it reaches the "jump" of 20 (or so) and then suddenly continues to work again as it should one by one after that.

I don't see why the scaling should have a "designed" effect somewhere arbitrary in the middle of the screen. I could understand it, if I would resize the host window causing the relative position in the emulated screen to change, but this is not the case here.

Anyway, I take a look at the code and see if I can find out why this happens. Of course I can switch off the scaling option and ignore it, but I think that an option that exists, should work properly.
sparhawk 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
Copper instructions and dma Jherek Carnelia Coders. Asm / Hardware 4 05 December 2019 23:33
Best way to mix blitting with copper and copper effects roondar Coders. Asm / Hardware 3 12 September 2016 14:12
Combining copper scrolling with copper background phx Coders. Asm / Hardware 14 16 June 2013 08:26
All asm instructions in one .s AGN Coders. General 0 15 September 2006 01:49
Instructions? Daz support.Hardware 8 12 July 2002 21:29

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


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