AGA first or OCS/ECS?

[Spec-Chum]

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?

[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.

[Spec-Chum]

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

[sandruzzo]

Originally Posted by 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.

Fast Copper?? How?

[Samurai_Crow]

Originally Posted by sandruzzo

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.

[chb]

Originally Posted by Samurai_Crow

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.

[Spec-Chum]

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...

[Samurai_Crow]

Originally Posted by chb

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.

[Toni Wilen]

Copper didn't get any updates in AGA.

[chb]

Originally Posted by Samurai_Crow

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.

Originally Posted by Samurai_Crow

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]

Originally Posted by Spec-Chum

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.

[Spec-Chum]

Originally Posted by chb

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."

[meynaf]

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.

[Samurai_Crow]

Originally Posted by chb

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.

[chb]

Originally Posted by Samurai_Crow

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.

[Samurai_Crow]

Originally Posted by chb

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.).

[chb]

Originally Posted by Samurai_Crow

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...

[sandruzzo]

With Aga we have more cycles per line, not faster copper, so we can have more instructions per line.

[meynaf]

Originally Posted by sandruzzo

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).