English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 25 December 2016, 17:05   #1
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 14
AGA first or OCS/ECS?

Hi all and Merry Christmas!

I'm brand new to Amiga coding and have just about managed to do a simple system takeover ( https://1drv.ms/u/s!AipiGCTl1HL_g4Mzga3k3DRLQXGJZg ) but, eventually anyway, I want to do some simple AGA demos. Nothing major, parallax stars, simple scroller, that kinda thing.

Anyway, should I dive straight into AGA or stick to the much more documented OCS/ECS modes whilst I'm learning? I've got the recommended hardware reference material and books and the autodocs etc

Is going from OCS to AGA pretty straight forward or is it recommended to just go straight to AGA?
Spec-Chum is offline  
AdSense AdSense  
Old 25 December 2016, 18:00   #2
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 909
Send a message via Yahoo to Samurai_Crow
Going from ECS to AGA is straightforward. Audio and blitter didn't change between them. All AGA adds is big sprites, more palette registers, fast Copper when the display is inactive, color bank switching for sprites and dual playfield mode, faster video fetching, and guaranteed access to Kickstart version 3.
Samurai_Crow is offline  
Old 25 December 2016, 18:15   #3
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 14
OK, cool, thanks.

So 99% of things I'm hoping to learn from ECS will translate over to AGA?

EDIT: Ignore that, you've clearly answered it above lol

Last edited by Spec-Chum; 25 December 2016 at 18:35.
Spec-Chum is offline  
Old 26 December 2016, 15:57   #4
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,109
Quote:
Originally Posted by Samurai_Crow View Post
Going from ECS to AGA is straightforward. Audio and blitter didn't change between them. All AGA adds is big sprites, more palette registers, fast Copper when the display is inactive, color bank switching for sprites and dual playfield mode, faster video fetching, and guaranteed access to Kickstart version 3.
Fast Copper?? How?
sandruzzo is offline  
Old 26 December 2016, 18:11   #5
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 909
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by sandruzzo View Post
Fast Copper?? How?
Two steps: 1) enable the control bit in the appropriate register, 2) disable the display DMA so the Copper can take over its bandwidth. The fast Copper is why Copper chunky is 4 times the horizontal resolution of ECS Copper plasma.
Samurai_Crow is offline  
Old 26 December 2016, 22:06   #6
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 48
Quote:
Originally Posted by Samurai_Crow View Post
Two steps: 1) enable the control bit in the appropriate register, 2) disable the display DMA so the Copper can take over its bandwidth. The fast Copper is why Copper chunky is 4 times the horizontal resolution of ECS Copper plasma.
I'm actually quite sure that copper speed did not change in AGA... the increased horizontal resolution for chunky plasma comes from the fact that due to the 256 color regs you can "buffer" the writes during two scanlines. But you can't have more than 57 color register writes* per scanline, both on OCS and AGA.

* using the copper, that is... but I've never seen a copper chunky effect using the cpu to write to the color regs.
chb is offline  
Old 26 December 2016, 22:14   #7
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 14
Another quick question, although I suspect the answer is subjective.

Both the "HowToCode7" guide and "Mapping the Amiga" book state (paraphrase) "Do NOT poke registers on AGA, use the OS routines". The HTC7 guide even goes so far as to say code using OS will be 20 times (?) faster due to no wait-states in the ROM code.

So, if I intend to code an (albeit simple) AGA demo, should I do it "by the book" with OS calls or "hit the metal"?

I'll be using asm if that makes any difference, but I am competent in C too...
Spec-Chum is offline  
Old 26 December 2016, 22:18   #8
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 909
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by chb View Post
I'm actually quite sure that copper speed did not change in AGA... the increased horizontal resolution for chunky plasma comes from the fact that due to the 256 color regs you can "buffer" the writes during two scanlines. But you can't have more than 57 color register writes* per scanline, both on OCS and AGA.

* using the copper, that is... but I've never seen a copper chunky effect using the cpu to write to the color regs.
When doing 12 bit color on an AGA Copper chunky screen you are using the same circuit that allows the 2 bank switch commands between the even bits and odd bits for the color register writes. If the Copper were the same speed as ECS it would take about 6 rows of pixels to update a 256 of true color palette entries between Intuition screens.
Samurai_Crow is offline  
Old 26 December 2016, 22:21   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,924
Copper didn't get any updates in AGA.
Toni Wilen is offline  
Old 26 December 2016, 22:31   #10
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 48
Quote:
Originally Posted by Samurai_Crow View Post
When doing 12 bit color on an AGA Copper chunky screen you are using the same circuit that allows the 2 bank switch commands between the even bits and odd bits for the color register writes. If the Copper were the same speed as ECS it would take about 6 rows of pixels to update a 256 entry of true color palette entries.
I don't fully understand what you are saying... on AGA,color bank and upper/lower bits are selected by writing to bplcon3. I do not see how this can speed up the copper writes?

On AGA you get approx. 57 color changes per line (a bit less, because you need to write to bplcon3 also), so you can e.g. change ~110 colors in two scanlines, giving you a 3x2 copper chunky. I've never seen something better than fullscreen 3x2 copper chunky, could you give an example of such an effect or game?

On OCS, using 4bpl mode and sprites, you could do 4x1 with ~55 or so pixels per line. Less usefull indeed, but that's not because of the copper speed - you just have less color registers.

Quote:
Originally Posted by Samurai_Crow View Post
If the Copper were the same speed as ECS it would take about 6 rows of pixels to update a 256 entry of true color palette entries.
Yes, and it indeed takes that long. Until I'm completely mistaken, copper is the same on OCS and AGA.

EDIT: Tony beat me.
chb is offline  
Old 26 December 2016, 22:37   #11
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 48
Quote:
Originally Posted by Spec-Chum View Post
Another quick question, although I suspect the answer is subjective.

Both the "HowToCode7" guide and "Mapping the Amiga" book state (paraphrase) "Do NOT poke registers on AGA, use the OS routines". The HTC7 guide even goes so far as to say code using OS will be 20 times (?) faster due to no wait-states in the ROM code.

So, if I intend to code an (albeit simple) AGA demo, should I do it "by the book" with OS calls or "hit the metal"?

I'll be using asm if that makes any difference, but I am competent in C too...
Well, there were mainly two reasons for using the OS on AGA:


1) Contrary to ECS, Commodore never officially documented the chipset, so they could change all AGA registers in any new revision (and probably would have done so). As there will be no new Amiga chipsets, that reason is not valid anymore.
2) If chipram bandwidth is low, ROM functions are indeed faster, but if your screenmode leaves enough room for the cpu (and on AGA that's at lower resolutions mostly the case) that argument is also void.


So, I'd say it comes down to your personal preferences.
chb is offline  
Old 27 December 2016, 01:24   #12
Spec-Chum
Registered User

 
Join Date: Dec 2016
Location: England
Posts: 14
Quote:
Originally Posted by chb View Post
Well, there were mainly two reasons for using the OS on AGA:


1) Contrary to ECS, Commodore never officially documented the chipset, so they could change all AGA registers in any new revision (and probably would have done so). As there will be no new Amiga chipsets, that reason is not valid anymore.
2) If chipram bandwidth is low, ROM functions are indeed faster, but if your screenmode leaves enough room for the cpu (and on AGA that's at lower resolutions mostly the case) that argument is also void.


So, I'd say it comes down to your personal preferences.
Just as I thought reallly, thanks

PS this makes me sad: "As there will be no new Amiga chipsets, that reason is not valid anymore."
Spec-Chum is offline  
Old 27 December 2016, 11:28   #13
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Even if new Amiga chipsets were to come out now, the reason would still be invalid - as changing the chipset would now break many programs.

About ROM functions being faster, it's just plain wrong regardless of the screen mode when the code is located in fastmem (true fastmem, that is). Actually, quite the opposite in many cases - ROM code can really be slower.

That said, there are still valid reasons why to use the OS. The program can then multitask happily and not use 100% cpu permanently, screen grabs can be made using the relevant software and you can hit the disk without much care.

Personnally I would recommend using the OS for screen handling and keyboard+mouse input management, but hit the screen's memory buffer directly.
meynaf is offline  
Old 29 December 2016, 12:07   #14
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 909
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by chb View Post
I don't fully understand what you are saying... on AGA,color bank and upper/lower bits are selected by writing to bplcon3. I do not see how this can speed up the copper writes?

On AGA you get approx. 57 color changes per line (a bit less, because you need to write to bplcon3 also), so you can e.g. change ~110 colors in two scanlines, giving you a 3x2 copper chunky. I've never seen something better than fullscreen 3x2 copper chunky, could you give an example of such an effect or game?

On OCS, using 4bpl mode and sprites, you could do 4x1 with ~55 or so pixels per line. Less usefull indeed, but that's not because of the copper speed - you just have less color registers.



Yes, and it indeed takes that long. Until I'm completely mistaken, copper is the same on OCS and AGA.

EDIT: Tony beat me.
The Copper doesn't go faster when the display DMA is active. It is a reallocation of bitplane DMA that allows it to update the screen registers in 2 rows of pixels between Intuition screens.

Anyway this is trivia in the age of the SuperAGA core that does actual chunky modes on the Vampire board and UAEGfx on the emulator settings.
Samurai_Crow is offline  
Old 29 December 2016, 12:28   #15
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 48
Quote:
Originally Posted by Samurai_Crow View Post
The Copper doesn't go faster when the display DMA is active. It is a reallocation of bitplane DMA that allows it to update the screen registers in 2 rows of pixels between Intuition screens.
Do you have any documentation or examples on this? I highly doubt copper is any different on AGA, as Toni Willen said, there were no updates. Updating all 256 color registers in 24 bit needs 528 copper moves (512 upper/lower color regs + 16 x BPLCON3), that's just impossible to do in 2 lines even if copper could use all memory cycles, including the even ones (which it cannot). You'd need some FMODE-burst thing for the copper, which isn't there.

As said, I'd be highly interested if you'd prove me wrong, because this would open a lot of new possibilities, but I've never seen any hint that something like you describes exists.
chb is offline  
Old 29 December 2016, 13:35   #16
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 909
Send a message via Yahoo to Samurai_Crow
Unhappy

Quote:
Originally Posted by chb View Post
Do you have any documentation or examples on this? I highly doubt copper is any different on AGA, as Toni Willen said, there were no updates. Updating all 256 color registers in 24 bit needs 528 copper moves (512 upper/lower color regs + 16 x BPLCON3), that's just impossible to do in 2 lines even if copper could use all memory cycles, including the even ones (which it cannot). You'd need some FMODE-burst thing for the copper, which isn't there.

As said, I'd be highly interested if you'd prove me wrong, because this would open a lot of new possibilities, but I've never seen any hint that something like you describes exists.
It appears I cannot confirm it from any sources on the Web including AGA Guide. When I last discussed it was at an Amiga DevCon in 1998 in St. Louis, Missouri. That may have been discussion of future chipset possibilities (that were ultimately rejected by Amiga Inc.).
Samurai_Crow is offline  
Old 29 December 2016, 14:05   #17
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 48
Quote:
Originally Posted by Samurai_Crow View Post
It appears I cannot confirm it from any sources on the Web including AGA Guide. When I last discussed it was at an Amiga DevCon in 1998 in St. Louis, Missouri. That may have been discussion of future chipset possibilities (that were ultimately rejected by Amiga Inc.).
Ah, pity really... redirecting bitplane dma to color registers would have been at least a nice hackish 12/16-bit chunky mode, or even a 24/32-bit lowres truecolor display, probably for little effort in terms of gate count. Sad it apparently did not happen...
chb is offline  
Old 29 December 2016, 16:14   #18
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,109
With Aga we have more cycles per line, not faster copper, so we can have more instructions per line.
sandruzzo is offline  
Old 29 December 2016, 17:46   #19
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,457
Quote:
Originally Posted by sandruzzo View Post
With Aga we have more cycles per line, not faster copper, so we can have more instructions per line.
There aren't more cycles per line. AGA owes its bandwidth to 32-bit and double CAS memory accesses - and this is for display dma only (though cpu can also do 32-bit).
meynaf 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
PacMan '96 - AGA or OCS/ECS? liviux76 support.Games 32 19 November 2016 19:50
AGA Upgrade for ECS/OCS Games? slowtide project.Amiga Game Factory 3 03 December 2013 21:11
Chaos Engine 2, AGA vs. OCS/ECS? rsn8887 Amiga scene 16 17 November 2012 16:12
OCS/ECS , AGA Diffrencies Kyon New to Emulation or Amiga scene 7 10 June 2009 12:43
ecs ocs games on aga memothejanitor support.Apps 4 16 June 2007 05:30

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 03:05.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.38286 seconds with 14 queries