Copper-generate WB Backdrop

[yorgle]

Hey all. I recently came across this video:

http://www.youtube.com/watch?v=ZmilpGXwcJk

And I asked about his Workbench backdrop, which is "just a copper list generated by a program called waverlauf, or something like that".  

Anyone know exactlty what app it might be? My google-fu is failing me today.

Also, anyone know if such a thing exists for 1.3?

[Franko]

Try here on AmiNet, lots of different utils/patches for creating a copper background on WB...

CopperMaster for example...

http://aminet.net/search?query=copper

[commodorejohn]

I've wondered how many colors the Copper can change, how quickly - be kind of fun to make a low-res true-color bitmap for a backdrop

[Minuous]

I'm familiar with the program, it's called "WBVerlauf".

http://aminet.net/package/util/wb/WBVerlauf20

[trekiej]

I hope this not off topic.
How fast can the colors be changed in the 32 color registers?

[commodorejohn]

I hope this not off topic.
How fast can the colors be changed in the 32 color registers?

I looked back over some of the documentation just now - if I'm not mistaken, Copper MOVEs take 560ns (four cycles) to execute. Running with my true-color idea, that would make a bitmap of 80x(screen height) theoretically possible, though I don't know how stable it'd be in practice.

[yorgle]

Excellent! Thanks!

[Franko]

I looked back over some of the documentation just now - if I'm not mistaken, Copper MOVEs take 560ns (four cycles) to execute. Running with my true-color idea, that would make a bitmap of 80x(screen height) theoretically possible, though I don't know how stable it'd be in practice.

There were a few programs for displaying copper coloured pics on the workbench on AmiNet years ago (can't remember their names though) but they were very tricky to edit/create pics with and the results were pretty poor, think thats why they didn't catch on...

[vidarh]

I looked back over some of the documentation just now - if I'm not mistaken, Copper MOVEs take 560ns (four cycles) to execute. Running with my true-color idea, that would make a bitmap of 80x(screen height) theoretically possible, though I don't know how stable it'd be in practice.

You're pretty much right, as far as I remember. The caveat is that anything else that can steal DMA cycles will cause the copper to miss one or more colour changes, and the blitter and CPU will pretty much stall on any accesses to chip RAM while you're doing this. This is from the hardware guide:

Disk DMA, audio DMA, display DMA, and sprite DMA all have the highest
priority level.  Display DMA has  priority  over sprite DMA under certain
circumstances.  Each of these four devices is allocated a group of time
slots during each horizontal scan of the video beam. If a device does not
request one of its allocated time slots, the slot is open for other uses.
These devices are given first priority because missed DMA cycles can cause
lost data, noise in the sound output, or on-screen interruptions.

The Copper has the next priority because it has to perform its operations
at the same time during each display frame to remain synchronized with the
display beam sweeping across the screen.

The lowest priorities are assigned to the blitter and the 68000, in that
order. The blitter is given the higher priority because it performs data
copying, modifying, and line drawing operations operations much faster
than the 68000.

In other words, any disk, audio, display or sprite DMA can or will interfere.

[trekiej]

I was wondering if one could use a single bit plane for higher resolution and switch out the single color register with a new color. I am not for sure how it would be timed or even be fast enough.

[commodorejohn]

There were a few programs for displaying copper  coloured pics on the workbench on AmiNet years ago (can't remember their  names though) but they were very tricky to edit/create pics with and  the results were pretty poor, think thats why they didn't catch on...

Well, the resolution would be pretty crap, but on the other hand, you'd have 12-bit true color. Pictures shouldn't be that hard to generate, so I'd blame it more on poor tools than any actual complexity of the task (really, all you'd be doing is a straight chain of MOVEs with WAITs at the end of each line.) Probably work better with visually simple, color-heavy images - the Windows XP "Bliss" wallpaper, for example, would look pretty good.

I was wondering if one could use a single bit  plane for higher resolution and switch out the single color register  with a new color. I am not for sure how it would be timed or even be  fast enough.

That was basically what I was thinking of doing, but it's fairly slow - you could only achieve 80x(height), and even that might not be reliable.

You're pretty much right, as far as I remember. The  caveat is that anything else that can steal DMA cycles will cause the  copper to miss one or more colour changes, and the blitter and CPU will  pretty much stall on any accesses to chip RAM while you're doing this.  In other words, any disk, audio, display or sprite DMA can or will  interfere.

Bummer. Probably not very stable, then - 40-wide might be a better shot, but then you're getting into ridiculously low resolution...

[Khephren]

I looked back over some of the documentation just now - if I'm not mistaken, Copper MOVEs take 560ns (four cycles) to execute. Running with my true-color idea, that would make a bitmap of 80x(screen height) theoretically possible, though I don't know how stable it'd be in practice.

You could also use DynamicHires, changing palettes per scanline, still gives very nice results, at a decent resolution. Several art programs will output this mode (HAMlab, ADpro and, I think IFFPro on the PC). I'll find some examples in a bit.

some forum threads:
http://eab.abime.net/archive/index.php/t-43475.html
http://ada.untergrund.net/forum/index.php?action=vthread&forum=4&topic=386

forgot to say, HAMlab is now free, and can be got from here http://ftp://nexus.polaris.net/pub/forager/Amiga

[Franko]

@ commodorejohn

It's like vidarh said, using a copper background to create a pic will be very sore on the eyes, as every time the HD or floppy does anything or even moving the mouse and opening windows causes the copper display to flicker change colours and be generally just too messy to be of any use...

I'll need to dig out the ones I tried years ago to show you why these utils/patches never caught on, unless you don't mind the eye strain they cause...

[commodorejohn]

You could also use DynamicHires, changing palettes per scanline, still gives very nice results, at a decent resolution. Several art programs will output this mode (HAMlab, ADpro and, I think IFFPro on the PC).

You can indeed - I used to use a similar approach for boot screens on my Apple IIgs. I just thought it would be an amusing novelty, is all.

Actually, the IIgs approach might be better overall - it used custom palettes shared over multiple similar lines, selected at conversion time. On the IIgs this was due to hardware limitations, but on the Amiga it'd help to cut down on the Copper bandwidth (which I gather from one of the threads on the subject is a limiting factor, at least on machines with no fast RAM.)

[trekiej]

I do not know the full capabilities of the custom chips.
So here goes.
1. Use a single bit plane
2. Load the serial-izer with all one's.
3. Rotate them so you would not need to load them any more.
4. Load the colors in to location 1 of the 32 color registers.
5. Time it.
It would be nice if the Ram Address Generator could be programmed to act as a chunky style pixel retriever.