How many times on a single scanline can Copper swap EHB palette?

[ImmortalA1000]

So I was reading about Spectrum 512 for the ST and it isn't just 16 colours per scanline via rasters, it actually races the beam and changes the palette three times per scanline. I only know of Amiga modes that change the palette once per scanline.

Could someone tell me what is the maximum number of times per scanline you can change the 32 colour palette when you are displaying EHB on OCS Amigas.

Also if this is possible in interlace mode. I think from memory the limit is 80 horizontal low resolution non interlaced pixels but not sure.

[a/b]

Little over 1. Interlace doesn't affect it.

[ImmortalA1000]

How about 32 colour mode?

If the ST shifter can change each of the 16 colours three times per scanline the Copper must be able to do at least 48 colours per scanline in 4 bitplanes if not more to match the ST Spectrum 512 routines.

[roondar]

Originally Posted by ImmortalA1000

How about 32 colour mode?

If the ST shifter can change each of the 16 colours three times per scanline the Copper must be able to do at least 48 colours per scanline in 4 bitplanes if not more to match the ST Spectrum 512 routines.

I've assumed a 320 pixel wide screen without scrolling to make things easier to explain (as the actual total number of colours that can be changed differs based on horizontal display width when using more than 4 bitplanes).

The Copper can change up to 56,5 registers* per scanline in modes <=4 bitplanes, of which 320/8=40 fall in the bitplane DMA area (meaning 40 of them). This means that 16,5 changes can be done during the horizontal blank.

In 5 bitplane mode, the number during the bitplane DMA drops to 320/12=26,5** for a total of 42 changes per scanline. In 6 bitplane mode, the number during the bitplane DMA drops further to 320/16=20, for a total of 36 changes per scanline.

Note that in all cases, the CPU can also be used to change colours, though this is usually not done on the Amiga. Also note that on the ST, the shifter doesn't change any colours, this is normally done using the CPU.

*) assuming PAL and no Copper waits between scanlines.
**) actually 26 and 2/3rds but for our purposes this difference is not relevant

[mc6809e]

Originally Posted by roondar

Note that in all cases, the CPU can also be used to change colours, though this is usually not done on the Amiga. Also note that on the ST, the shifter doesn't change any colours, this is normally done using the CPU.

Yeah, there seems to be this idea that the Amiga CPU can't be used to handle display tricks and that the copper must be used. Not sure why the idea persists.

The copper can even been turned off completely and the CPU left to reset pointer registers, etc to maintain the display. I'm convinced that Jay Miner intended for the CPU at times to participate in manipulting the display which is why hsync interrupts are possible.

There are probably some interesting sprite tricks that can be done by using the CPU to update sprite registers during a scanline -- "racing the beam".

One experiment I've wanted to try for a long time is using the CPU to maintain the display while the copper runs a kind of "blitter-list". It's possible I believe to get the copper to handle a "blitter-list" that spans and crosses the start of VBLANK.

Smething like this:

      
      DC.W COP1LCL, A1
      DC.W COP2LCL, B1
A1:     
      DC.W $0001, 0000   ; wait for blitter finish - VBLANK takes us here
      DC.W $0501, $7F01 ; check for possible "danger zone"
      DC.W COPJMP2, $0000 ; early enough to load blitter registers
      DC.W $0701, $7F00 ; possible VBLANK coming - wait till past "danger zone"
B1:
      DC.W BLTCON0, xxxx
      DC.W BLTCON1, xxxx
...
      DC.W BLTSIZE, blitsize
      DC.W COP1LCL, A2
      DC.W COP2LCL, B2
A2:
      DC.W $0001, 0000 ;wait for blitter finish
      DC.W $0501, $0701
      DC.W COPJMP2, $0000
      DC.W $0701, $7F01
B2:
      DC.W DC.W BLTCON0, xxxx

[roondar]

Originally Posted by mc6809e

Yeah, there seems to be this idea that the Amiga CPU can't be used to handle display tricks and that the copper must be used. Not sure why the idea persists.

I guess it's because using the Copper is simply easier, certainly if the timing is critical and you want compatibility across CPU types/speeds. But you're absolutely correct that the CPU can do all/most of the things the Copper can do.

The copper can even been turned off completely and the CPU left to reset pointer registers, etc to maintain the display. I'm convinced that Jay Miner intended for the CPU at times to participate in manipulting the display which is why hsync interrupts are possible.

Sounds reasonable. A raster line interrupt is one thing, but you can interrupt the CPU at any point during the raster line, which does fit your idea.

There are probably some interesting sprite tricks that can be done by using the CPU to update sprite registers during a scanline -- "racing the beam".

One experiment I've wanted to try for a long time is using the CPU to maintain the display while the copper runs a kind of "blitter-list". It's possible I believe to get the copper to handle a "blitter-list" that spans and crosses the start of VBLANK.

Smething like this:
<<...>>>

Interesting, that might actually be a very good approach in some circumstances

[mc6809e]

Originally Posted by roondar

\
Interesting, that might actually be a very good approach in some circumstances

I was thinking 3d poly rendering.

It would be nice to have the blitter running line draws, ploy fills, etc, while the CPU spends it's time running calculations, especially all the MULS and DIVS instructions.

A naive approach would involve using blitter finished interrupts but in practice these are often too slow. Even if the Lotus II trick is used (rewriting the int vector to create a chain of code) there's a problem with interrupt latency caused if the CPU is in the middle of one of those MULS or DIVS instructions (plenty in 3d code). A MULS is between 38 and 70 cycles while a DIVS is between 120 to more than 150 cycles. If the blitter finishes and interrupts at the beginning of executing a DIVS it will sit idle until the CPU can finish and service the interrupt. And then that response takes another 40+cycles before the first blitter register can even be loaded.

[ImmortalA1000]

Originally Posted by roondar

I've assumed a 320 pixel wide screen without scrolling to make things easier to explain (as the actual total number of colours that can be changed differs based on horizontal display width when using more than 4 bitplanes).

The Copper can change up to 56,5 registers* per scanline in modes <=4 bitplanes, of which 320/8=40 fall in the bitplane DMA area (meaning 40 of them). This means that 16,5 changes can be done during the horizontal blank.

In 5 bitplane mode, the number during the bitplane DMA drops to 320/12=26,5** for a total of 42 changes per scanline. In 6 bitplane mode, the number during the bitplane DMA drops further to 320/16=20, for a total of 36 changes per scanline.

Thank you for the detailed explanation

So as I understand it if you have 16 colours and you can change 56 registers I guess that means a maximum of 72 colours (unless each R G B component counts as one for a palette colour definition....it's been a long time since I thought about this stuff!!)

Would also make 32 colours + max of 42 changes to give a max per scanline of 74. Of course if you need to make the changes too close to each other it gets lower.....much closer to the system friendly standard EHB+copperlist method.

Given the amount of Copper time being thrown at a static display you might as well just make a bit of effort with an EHB optimised image using modern tools and make it interlaced which technically gives you 128 colours per even/odd scanline pair and this is the way to go with simple scanline based palette changes. On the ST the same area of the screen subjectively is 1 single lo-res scanline on display as there is no interlaced modes on ST except the 640x400 70hz 31khz mono mode).

(I only mention the ST's Shifter chip because as I understand it that is what's used to do weird raster dependent effects like opening bottom border etc)

[pandy71]

Originally Posted by ImmortalA1000

Thank you for the detailed explanation
So as I understand it if you have 16 colours and you can change 56 registers I guess that means a maximum of 72 colours (unless each R G B component counts as one for a palette colour definition....it's been a long time since I thought about this stuff!!)

Would also make 32 colours + max of 42 changes to give a max per scanline of 74. Of course if you need to make the changes too close to each other it gets lower.....much closer to the system friendly standard EHB+copperlist method.

Given the amount of Copper time being thrown at a static display you might as well just make a bit of effort with an EHB optimised image using modern tools and make it interlaced which technically gives you 128 colours per even/odd scanline pair and this is the way to go with simple scanline based palette changes. On the ST the same area of the screen subjectively is 1 single lo-res scanline on display as there is no interlaced modes on ST except the 640x400 70hz 31khz mono mode).

(I only mention the ST's Shifter chip because as I understand it that is what's used to do weird raster dependent effects like opening bottom border etc)

Sorry for interrupting this interesting conversation.

Amiga and Atari ST are comparable in terms of available bandwidth for memory so comparable techniques can be used.
Amiga on top of same/similar memory bandwidth (difference is only in lower CPU clock) offer also additional hardware not present in ST and as such offer more capabilities. ST with very careful and time consuming CPU usage may provide very limited functionality (when compared to Amiga HW functionality) - interlace on ST for example is probably not true interlace but rather line doubling, EHB and HAM are HW modifiers of the CLUT content, 5 and 6 bitplanes in low res mode are not possible on ST HW, in high res only mono and only if you use dedicated display (but noninterlaced), med res only 2 bitplanes, lack of Copper push on CPU necessity to do time critical synchronization - or by precise cycle counting or by waiting in pulling mode... there is many more differences offering Amiga advantages over Atari ST but, with dedicated and passionate coders Atari ST was capable to reach excellence (considering HW capabilities).
Examples:
http://www.leonik.net/dml/sec_pcs.py
http://www.leonik.net/dml/sec_crypto.py
https://atari.8bitchip.info/movpst.php
https://gtello.pagesperso-orange.fr/mpste_e.htm

Most of the above (if not all) techniques can be used in Amiga almost directly - but seem just nobody in Amiga is interested in this.

[ImmortalA1000]

I never really thought about it before but like I said you would be better off using EHB + palette swaps that wasting even more copper time changing during scanline being drawn so it's interesting but kind of doesn't matter from an artists point of view.

There is a difference between true interlace image generation and faking it. I know the Atari 800 etc can do true interlace (odd number of scanlines or something, it's been a decade!) but the C64 can not (even number of scanlines drawn per frame?). Not sure where the ST fits into this but ultimately the ST had crappy borders like Spectrum/C64 etc and the Amiga does not so even on a 1:1 basis the Amiga is the only one that can do everything the Atari ST Beat Dis' demo does via Blitz/AMOS Basic (sample playback, fullscreen image, smooth vertical scrolling. There was an 'interlaced' monochrome screen emulator though for the ST which essentially just displayed different images every 50/60th of a second using the 640x200 screen. Atari could easily have put in firmware assist to give you 640x400 in 4 colours because the Amiga can only update a full interlace display once every 25 fps (because that's how domestic TVs displayed full broadcast resolution in PAL).

The best games on Amiga always found the best use for each individual component of the design (Beast 1, Lotus II, Turrican 3 etc) so you might as well let the copper get on with simple palette slicing and use the CPU for something the copper can't do.

[pandy71]

Originally Posted by ImmortalA1000

I never really thought about it before but like I said you would be better off using EHB + palette swaps that wasting even more copper time changing during scanline being drawn so it's interesting but kind of doesn't matter from an artists point of view.

AGA can use palette swaps - pre-AGA Amiga's not - my impression is that also Atari is unable to use palette swaps approach. Instead of palette swaps, pre-AGA Amiga's and Atari need to update palette (CLUT).

Originally Posted by ImmortalA1000

Atari could easily have put in firmware assist to give you 640x400 in 4 colours because the Amiga can only update a full interlace display once every 25 fps (because that's how domestic TVs displayed full broadcast resolution in PAL).

Nope, interlace display doesn't need to be updated once every 25 fps - in fact SSA format update fields to get smoother motion, same approach is common for video titlers - field aware update deliver smoother motion (you can alternatively do sub pixel scrolling but this will be overkill for MC68k@8MHz)

Originally Posted by ImmortalA1000

The best games on Amiga always found the best use for each individual component of the design (Beast 1, Lotus II, Turrican 3 etc) so you might as well let the copper get on with simple palette slicing and use the CPU for something the copper can't do.

It is up to developer - Copper usage is beneficial as it is always synchronous with pixels on screen, also it can provide perfect timing - something CPU can't do unless you put CPU in pooling and design code with perfect cycle count - i think this is Atari ST approach.

But at some point you end with HW limitations - this is valid for Amiga and for Atari.

[ImmortalA1000]

All domestic CRT TV displays updated broadcast quality PAL full resolution images at 25fps maximum, only half the image, is updated. Even if on Amiga you updated a hi-res interlace bitmap image you would only get half that image displayed in a single frame/50, it would take two frames/50 to display odd and even scanlines on the TV. That's all I meant about interlace, limitation of PAL display technology to achieve 625 line transmitted image.

The 68000 CPU is far to useful a resource to waste on palette swaps on the Amiga when the copper can do it for you. The ST needs to involve some CPU instructions to execute rasters like most other computers without Jay Miner's input in the design.

[roondar]

Originally Posted by ImmortalA1000

Thank you for the detailed explanation

So as I understand it if you have 16 colours and you can change 56 registers I guess that means a maximum of 72 colours (unless each R G B component counts as one for a palette colour definition....it's been a long time since I thought about this stuff!!)

Would also make 32 colours + max of 42 changes to give a max per scanline of 74. Of course if you need to make the changes too close to each other it gets lower.....much closer to the system friendly standard EHB+copperlist method.

Ah, I only just noticed your reply, sorry about that!

I don't think this'll work

The 56 colours you change per scanline have to be part of the colour register set you have, so you can't simply add those on top of the 16 registers in 4 bitplane mode and come to 72 colours in a scanline. I'd say the best case is changing all 16 colours in the horizontal blank and then change colours as needed while moving through the scanline, for a total of (up to*) 56 colours per scanline.

Based on your post, I did consider keeping some colours static and changing others, but this sadly doesn't actually help you: you get 40 colour changes per scanline during the visible part of the image, the rest happens in the horizontal blank. You might be able to increase this somewhat by using Sprites as part of the image with preset, fixed, colours but that is quite limited due to Sprite coverage limits and the colours will be identical all the way through the image (no time to change them).

Thinking about it some more, you may be able to push it even further by electing to change Sprite colours for part/all of the H-Blank instead of bitplane colours and re-use some of the bitplane colours already set last scanline. This will get extremely tricky to get right, but you might just be able to make use of this to make some images get more colours in some scanlines while not exceeding the Copper limits.

Might be an interesting experiment, but it does feel like a huge headache to get right

Edit: a small addition, my comments are about OCS systems only. For AGA things are different, with a much wider CLUT and palette bank switching through hardware as well as needing two Copper writes (plus one more to set BPLCON3 - worst case of three moves when changing a single colour, best case is doing blocks of changes to limit BPLCON3 changes) to change one 24 bit colour. So for AGA, things are different.

*) depending on what colours the image needs and can be pushed in time by the Copper

[pandy71]

Originally Posted by ImmortalA1000

All domestic CRT TV displays updated broadcast quality PAL full resolution images at 25fps maximum, only half the image, is updated. Even if on Amiga you updated a hi-res interlace bitmap image you would only get half that image displayed in a single frame/50, it would take two frames/50 to display odd and even scanlines on the TV. That's all I meant about interlace, limitation of PAL display technology to achieve 625 line transmitted image.

Yes, too simplify - you can update 256 lines 50 times per second or 512 lines 25 per second however if you clever you can balance between vertical resolution and motion accuracy, if you have sufficient amount of CPU power you may even go further and introduce subpixels.
There is only one issue in Amiga - you never know which filed dominate in interlace as top/bottom field flag may be inconsistent after start of display (there is no clear state machine to define LOF bit in VPOSx register - it can only toggle on field basis - this can be probably workaround in software somehow - can be important as NTSC and PAL usually use opposite field dominance) - my assumption is that's why most of the interlace software on Amiga use developer safe approach and prefer to update screen with frame rate not with field rate...

Originally Posted by ImmortalA1000

The 68000 CPU is far to useful a resource to waste on palette swaps on the Amiga when the copper can do it for you. The ST needs to involve some CPU instructions to execute rasters like most other computers without Jay Miner's input in the design.

Only if you have CPU with cache and/or FAST RAM - if your code is located in memory connected to chipset bus then there is no substantial difference. My impression is that this is how dynamic color screen in ST works - CPU is used to transfer data directly from disk to CLUT (to avoid bus congestion).
Copper is beneficial as it is perfectly synchronized with beam so you can in theory update colors behind beam (perform classical beam race).
If Copper could use separate local memory (like 16KiB) then this could be really nice feature... sadly Amiga HW developers didn't provided such feature (something like 2x 6264 SRAM could be nice but there is pin limit in Agnus).

[mc6809e]

Originally Posted by pandy71

There is only one issue in Amiga - you never know which filed dominate in interlace as top/bottom field flag may be inconsistent after start of display (there is no clear state machine to define LOF bit in VPOSx register - it can only toggle on field basis - this can be probably workaround in software somehow - can be important as NTSC and PAL usually use opposite field dominance) - my assumption is that's why most of the interlace software on Amiga use developer safe approach and prefer to update screen with frame rate not with field rate...

I was under the impression that the LOF bit in VPOSw could be written to and that if LACE was off in BPLCON0 LOF would not toggle.

If Copper could use separate local memory (like 16KiB) then this could be really nice feature... sadly Amiga HW developers didn't provided such feature (something like 2x 6264 SRAM could be nice but there is pin limit in Agnus).

Even a tiny bit of static RAM just for the CPU would been have nice.

I've been toying around with the idea of jumping to kickstart code segments to save chipram bus cycles. There's copy code that might be useful.

Even loading longword constants from kickstart may save a few DMA cycles.

[ross]

Originally Posted by mc6809e

I was under the impression that the LOF bit in VPOSw could be written to and that if LACE was off in BPLCON0 LOF would not toggle.

And your impression is right, that's what the LACE bit does: if set it just toggles the LOF bit at to the end of the current field.
So via software you can easily decide which to display, the one with VTOTAL+1 or VTOTAL+2 lines (VTOTAL+1+LOF) .

[mc6809e]

Here's a question: if VPOS is written to, can we fool the hardware into generating a vertically longer display by resetting VPOS to an earlier line? My guess is yes to some extent, but a CRT would need its vertical size control adjusted.

[ross]

Originally Posted by mc6809e

Here's a question: if VPOS is written to, can we fool the hardware into generating a vertically longer display by resetting VPOS to an earlier line? My guess is yes to some extent, but a CRT would need its vertical size control adjusted.

Sure you can, you can 'shorten' or 'lengthen' the display, but the synchronization is not necessarily maintained.
Some OCS games do this with good results (usually to 'emulate' NTSC resolution over PAL).
But it's not trivial because you can't use copper to do it.

[pandy71]

Originally Posted by mc6809e

I was under the impression that the LOF bit in VPOSw could be written to and that if LACE was off in BPLCON0 LOF would not toggle.

Ross already confirmed but yes, this is exactly how it works - issue is that LOF may be in one of two states before it start toggle - so from Amiga perspective LOF can be 0 or 1 and toggle - normally you don't care unless you doing animation on both fields to improve perceived smoothness.

Originally Posted by mc6809e

Even a tiny bit of static RAM just for the CPU would been have nice.

I've been toying around with the idea of jumping to kickstart code segments to save chipram bus cycles. There's copy code that might be useful.

Even loading longword constants from kickstart may save a few DMA cycles.

Yep, there is plenty small improvements possible and they will dramatically improve Amiga functionality but... they was never implemented so no chance to prove validity of those improvements.

And using kickstart as a fast memory is nothing new...

Originally Posted by ross

Sure you can, you can 'shorten' or 'lengthen' the display, but the synchronization is not necessarily maintained.
Some OCS games do this with good results (usually to 'emulate' NTSC resolution over PAL).
But it's not trivial because you can't use copper to do it.

But you can do this with Copper (since ECS/AGA) - only ICS/OCS can't access VPOSx by Copper.

Never saw any issues with CPU controlling VPOSW - especially that Copper may trig interrupt on particular line for CPU.

[ross]

Originally Posted by pandy71

But you can do this with Copper (since ECS/AGA) - only ICS/OCS can't access VPOSx by Copper.

I was specifically referring to the possible emulation of NTSC/60Hz in OCS.

In ECS+ it's trivial (and properly) done directly through BEAMCON0.
Setting NTSC mode generate a vsync with real NTSC equalization and serration pulses (not that in fact it creates problems on the various modern decoders even the 'incorrect' PAL signals during the vsync..).

Of course you can do it easily with the Copper, CDANG bit and VPOS on ECS+, and set all the vertical frequencies you want

Never saw any issues with CPU controlling VPOSW - especially that Copper may trig interrupt on particular line for CPU.

Sure, but it is no longer so simple, especially in a slightly more complicated environment such as that of a game in which various IRQs, perhaps at the same level, can arrive at the same time, where instructions of different duration 'move' the horizontal position of the IRQ trigger, or you set the blitter in BLTPRI mode which freezes the CPU (I'm talking about a bare environments, without real fast-ram and possible base machines).

Certainly feasible, but you have to be careful and know what you do, and it is a choice actually implemented in very few real cases.
On the contrary, doing it for testing is simple