English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 30 October 2020, 06:39   #1
Nightfox
Registered User

Nightfox's Avatar
 
Join Date: Apr 2016
Location: Perth, Australia
Posts: 256
Copper lists not on chip ram?

The ROM kernel reference manual says user copper lists do not have to be in chip ram which makes no sense to me. When creating copper lists by hardware assembly coding the copper list needs to be in chip ram. Why does a user copper list when doing systems programming not require it to be in chip ram?
Nightfox is offline  
Old 30 October 2020, 07:33   #2
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 46
Posts: 1,588
Send a message via Yahoo to Samurai_Crow
User copper lists are in a bytecode. Real copper lists are generated by MrgCop() which translates the bytecodes of several sources into one copper list in Chip RAM. It's redundant and slow.
Samurai_Crow is offline  
Old 30 October 2020, 09:48   #3
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 691
This is not rendundant, but necessary. The graphics.library holds three copper lists per viewport: The regular copper list that is responsible for filling the bitplane addresses and the screen colors, the copper list for the vsprite system, and the user copper list. All have different sources. Furthermore, more than one viewport can be placed on the view at a time, so the copper lists have to be merged into one. Now tell me how to do that without an intermediate representation.
Thomas Richter is offline  
Old 30 October 2020, 12:56   #4
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,325
Honestly, I've always thought that the OS way of handling many intersecting Copperlists on a single display was pretty good. The idea of a user Copper list makes sense, as does the idea of having an intermediate format to facilitate the merging process.

I obviously have no idea about how it's implemented under the hood, but the idea seems sound to me.
roondar is offline  
Old 30 October 2020, 14:45   #5
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 46
Posts: 1,588
Send a message via Yahoo to Samurai_Crow
I'm working on a replacement that uses a single node starting with a CWAIT equivalent and a variable number of CMOVEs stored as a variable-length structure. The reason for this is to allow merges to be promoted to full natural merge sort based on screen position.
Samurai_Crow is offline  
Old 30 October 2020, 18:06   #6
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 691
Quote:
Originally Posted by Samurai_Crow View Post
I'm working on a replacement that uses a single node starting with a CWAIT equivalent and a variable number of CMOVEs stored as a variable-length structure. The reason for this is to allow merges to be promoted to full natural merge sort based on screen position.
Well, try your luck, but it's less obvious than it seems. The graphics.library received an update in v37 where some operations such as SetRGB32() no longer go through the intermediate copper list and MrgCop(), but directly poke the screen copperlist.

This sounds trivial at first, but the problem here is that the copper wait instruction only receives the Y position modulo 256, and if there is any larger Y you have to wait for, you first have to wait for the last line (or a line larger than your Y), and then for the final position, potentially multiple times. This function was written in assembly, and - honestly - is close to incomprehensible.

So, sure, as you please, but "dragons be there".

As a side remark, one of the memory trashes and bugs we fixed in 3.1.4 was related to a "seemingly smart" caching of pointers that help to speed up copper processing if you just want to scroll the screen or move the sprite. Graphics keeps "cache pointers" for this in order not to go through a full MrgCop() once again. But unfortunately, in some situations missed to update the cache pointers that point to the right entry in the copper list, then trashing memory.
Thomas Richter is offline  
Old 30 October 2020, 18:23   #7
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 46
Posts: 1,588
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by Thomas Richter View Post
Well, try your luck, but it's less obvious than it seems. The graphics.library received an update in v37 where some operations such as SetRGB32() no longer go through the intermediate copper list and MrgCop(), but directly poke the screen copperlist.

This sounds trivial at first, but the problem here is that the copper wait instruction only receives the Y position modulo 256, and if there is any larger Y you have to wait for, you first have to wait for the last line (or a line larger than your Y), and then for the final position, potentially multiple times. This function was written in assembly, and - honestly - is close to incomprehensible.

So, sure, as you please, but "dragons be there".

As a side remark, one of the memory trashes and bugs we fixed in 3.1.4 was related to a "seemingly smart" caching of pointers that help to speed up copper processing if you just want to scroll the screen or move the sprite. Graphics keeps "cache pointers" for this in order not to go through a full MrgCop() once again. But unfortunately, in some situations missed to update the cache pointers that point to the right entry in the copper list, then trashing memory.
Mine is not backwards compatible at all. It's aiming to replace the View, ViewPort, ExtView, ExtViewPort, ColorMap and Sprite allocation and usage completely. In a future version, I may rework QBlit and friends and replace all of Graphics.library with VideoFX.library outright.

My complaint about CMOVE is that it does its translation at runtime rather than using preprocessor macros. Also, being able to sort whole sections of copper lists by their screen position opens up much flexibility for out-of-order encoding.

Without a doubt, Graphics.library is probably the weakest link with regard to chipset utilization. How do you add additional sprites when the allocation bitfields are stored in a UBYTE? Don't even get me started!

Edit:

On second thought, I'll probably keep the blitter controls the way they are so I don't need to rewrite the clipping routines and Layers.library. The only thing missing from QBlit is batch rendering support so I can just issue multiple blit nodes.

Last edited by Samurai_Crow; 30 October 2020 at 18:47.
Samurai_Crow 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
Two questions about OS legal screens/copper lists roondar Coders. System 8 16 December 2019 12:51
Copper lists are hard deimos Coders. Asm / Hardware 14 24 November 2019 14:03
sidecar ram, plus fast ram, chip ram behavior kaluce support.Hardware 6 21 May 2019 18:38
Couple of questions about Copper Lists jimmy2x2x Coders. General 2 21 November 2014 18:03
How 2MB chip ram with the Mini Megi Chip? Antti support.Hardware 6 04 June 2014 21:54

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 19:17.


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