10 January 2022, 01:27 | #1 |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
How many times on a single scanline can Copper swap EHB palette?
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. |
10 January 2022, 02:04 | #2 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,039
|
Little over 1. Interlace doesn't affect it.
|
11 January 2022, 08:47 | #3 |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
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. |
11 January 2022, 09:49 | #4 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Quote:
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 Last edited by roondar; 11 January 2022 at 10:06. |
|
11 January 2022, 16:28 | #5 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
Quote:
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: Code:
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 |
|
11 January 2022, 16:46 | #6 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Quote:
Quote:
Quote:
|
|||
11 January 2022, 17:17 | #7 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
Quote:
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. |
|
05 February 2022, 03:15 | #8 | |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
Quote:
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) |
|
05 February 2022, 21:23 | #9 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
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. |
|
06 February 2022, 01:03 | #10 |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
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. |
08 February 2022, 01:46 | #11 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Quote:
Quote:
But at some point you end with HW limitations - this is valid for Amiga and for Atari. |
|||
24 February 2022, 05:03 | #12 |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
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. |
24 February 2022, 13:41 | #13 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,411
|
Quote:
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 Last edited by roondar; 24 February 2022 at 14:01. |
|
24 February 2022, 21:16 | #14 | ||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
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... Quote:
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). |
||
25 February 2022, 15:13 | #15 | ||
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
Quote:
Quote:
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. Last edited by mc6809e; 25 February 2022 at 15:22. |
||
25 February 2022, 16:11 | #16 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
Quote:
So via software you can easily decide which to display, the one with VTOTAL+1 or VTOTAL+2 lines (VTOTAL+1+LOF) . |
|
25 February 2022, 16:34 | #17 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 372
|
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.
|
25 February 2022, 16:48 | #18 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
Quote:
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. |
|
26 February 2022, 00:00 | #19 | |||
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,771
|
Quote:
Quote:
And using kickstart as a fast memory is nothing new... Quote:
Never saw any issues with CPU controlling VPOSW - especially that Copper may trig interrupt on particular line for CPU. |
|||
26 February 2022, 01:58 | #20 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,475
|
Quote:
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 Quote:
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 |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Copper wait until end of scanline | Markowitch | Coders. Asm / Hardware | 2 | 04 October 2020 14:41 |
Copper WAIT for end of scanline > $80 | DanielAllsopp | Coders. Asm / Hardware | 7 | 03 June 2020 21:57 |
CustomColors - how many times can I switch the palette? | Marle | Coders. Blitz Basic | 9 | 02 May 2018 12:10 |
Can anyone here hack a single load Amiga game to add a copper list please? | ImmortalA1000 | Amiga scene | 10 | 19 January 2012 08:20 |
a painting program that let you change the palette per scanline | Michael Parent | request.Apps | 1 | 26 October 2009 22:09 |
|
|