Amiga Tech - Copper Chunky

[@Daytona675x]

I really like your calm way of talking, you could be a good teacher in "real life", thumbs up.

[@DutchRetroGuy]

Thanks!

[@MrDanielmckeats]

Wow! I like your real time demo and your pre-calculated version, especially how you realised those. Good job!

[@DutchRetroGuy]

@@MrDanielmckeats thanks! Glad you liked it, doing a Copper Chunky screen was something I always wanted to try!

[@ninjaalex-yf5io]

bring back so many memories when writing demos and discovering the copper's bugs by yourself. We didn't have internet back then...

[@DutchRetroGuy]

Yeah, these things were a lot harder when you didn't have all the modern tools we have today!

[@amipal24]

A fascinating insight into utilising the Amiga's hardware for unique effects not even considered by the designers!

[@DutchRetroGuy]

Yeah, the Copper rocks for this kind of stuff :)

[@ArneChristianRosenfeldt]

That is why you better avoid custom chips and CISC. I also despise complicated interrupt controllers. Let the software devs decide!

[@danyoutube7491]

@@ArneChristianRosenfeldt It's easy saying that when you don't have to work within the constraints of 1980s technology. There wasn't the massive amount of RAM and fast CPUs to easily display high-res, 16 bit colour graphics until 486 PCs in the early 90s started becoming more affordable for middle class families. It's also interesting and impressive that people work to be more efficient and are so clever as to make things possible that people hadn't thought could be done with this hardware.

[@ArneChristianRosenfeldt]

@@danyoutube7491 I was voting for something like Archimedes. CPU has half as much transistors than the CPU in Amiga. Unified RAM as on Atari computers saves us from expensive bridges with packages with many pins (everything is chip memory). Instead we add 16 more pins to the CPU. Amiga can use ROM and RAM parallel. So like this failed 16bit TI Computer ROM is made more important. On un-opinionated systems like the plus4 ROM sits on the common system bus.

[@PixelShade]

Awesome video mate! I always get a big smile on my face whenever I see a new video upload from you. This seriously great! Sharing knowledge like this is so important to Amiga community. Keep up the good work! :D

[@DutchRetroGuy]

Thanks! I'm hoping these videos will help others who want to code on the Amiga as well :)

[@heidirichter]

This was fantastic, great work! I love seeing and hearing about the various ways the Amigas uniquely flexible chipset could be used to generate all sorts of interesting effects. Would you consider a later video follow-up to this regarding what could be done on AGA, as I feel AGA is often overlooked and I'm really curious what could be done with the changes to the chipset, combined with the faster processors.

[@DutchRetroGuy]

Thanks! I am considering an AGA version as well, yeah. But if I do so, it'll be a while yet - I don't really want to do back-to-back videos with the same effect in them.

[@heidirichter]

@@DutchRetroGuy Fair enough, that's a good call, not only would it be less interesting for you, but it would also be less interesting for your audience to see this followed up too soon with an AGA version.

[@ilpojaaskelainen1552]

Great video! Copper chunky on A500 had been puzzling me too! Didn't see the bpl5dat & bpl6dat coming. Thumbs up for Troy's question: So, what is the final width record on AGA? Alien Breed 3D achieved 96 pixels (2x2) in width. Perhaps AGA effect could have something to do with texture mapping or so?

[@daweiisgood2392]

I hope you are ok. Looking forward to see what you bring next... The Amiga (pick model) is such a wonderful machine. :)

[@DutchRetroGuy]

Thanks, I'm close to figuring out what I want to show next ;)

[@naviamiga]

So interesting to see how these effects are put together. And they look great in motion. Great video.

[@DutchRetroGuy]

Glad you liked it!

[@wasabinator]

This was incredibly fascinating and so well presented!

[@DutchRetroGuy]

Thanks!

[@drzeissler]

This is very cool stuff, I would love to see something like this for some old and classic demo-effects on a 68060 Macintosh LC.

[@DutchRetroGuy]

Thanks for the compliment. I'm afraid that I'm not into classic Mac development, but would be interesting to see some demos on there for sure :)

[@drzeissler]

@@DutchRetroGuy demoscene-demos-macintosh Did not find early demoscene effects on these for my LC like rasterbars, starfield, copperbars, smooth scrolling etc. so I thought about using existant 68k code and give it a try on my LC. But I don't have experience on this.

[@DutchRetroGuy]

​@@drzeissler I wish I could help you with it, but I don't even know if there is a classic Mac community. I can tell you that Amiga code with these kind of tricks can't be used as the hardware is completly different outside of the processor :(

[@drzeissler]

@@DutchRetroGuy I know...

[@DutchRetroGuy]

@@drzeissler yeah, sorry - if you're interested in coding assembly it's obvious you already know this.

[@ScoopexUs]

Very nice and detailed. :) Keep up the good work!

[@DutchRetroGuy]

Thanks :)

[@arthurdaly3497]

So weird. I was just re-remembering about this possibility. Well actually I first thought about this possibility back in about 1987, after I wrote an assembler loop where I could see that I could change the colout pallete after about every 4 pixels horizontally

[@DutchRetroGuy]

I think I first heard of the term when I saw the readme for one of the 3D Copper demo’s I saw back around 2000. It’s an interesting effect for sure.

[@TonimanGalvez]

Really impressive, I am amazed by your clevernes. Well done.

[@arthurdaly3497]

Just wow. I knew all of this was probably possible and did a few bits of programming to investigate it back in the day, but you just went and did the whole thing. I blame my ADHD. I was like "yeah I know I can do that already, so I can't be bothered finishing it". I never even heard the term copper chunky pixel mode used by anyone else before this video, I thought it was something I'd come up with 🤣which noone else would ever know about

[@DutchRetroGuy]

Figuring out these kind of techniques on your own is one of the great things about the old platforms. Great stuff that you made something like this yourself back in the day. As for not finishing, you should see my AmigaDev directory on my PC - so many unfinished or half baked ideas 😆

[@MaxCarponera]

Man I coded a lot of copper chunky. My gropu chaps even put me the nick based on that.

[@Archimedes75009]

Great work, and great job explaining all this. Thank you.

[@lolotoobo06]

Really interesting. thanx

[@KevinSaunders]

Great video and effects, nicely presented also :)

[@DutchRetroGuy]

Thanks!

[@Steril707]

Good stuff as always, Roony.

[@stephenkennedy6358]

I realize the amiga had a leg up over the PC's of the day like the blitter and copper and various ham mode even though VGA had a slightly higher resolution of 640x480 and 256 colors before AGA came out. My question is at what time did the pc actually catch up and surpass the amiga in the graphics department.

[@DutchRetroGuy]

That’s an interesting question because it really depends on how you look at it. When it comes to speedy 3D graphics for instance, you’re looking at a much earlier date than for 2D stuff. Considering only 2D for a moment, VGA was released in 1987 and could outdo the Amiga in terms of static images immediately (it may not have had HAM mode, but it did have many more shades of each colour to choose from). When looking at moving GFX (i.e. action games & demos), the Amiga held its own for longer. When I look at it myself, I’d argue you started seeing more impressive action games around 1990 and more impressive demos a little while after that (1993 perhaps?) - though there are always exceptions. I’m less aware of the PC demo scene so it may be that there’s better stuff from the early periods than I realise though! Looking at the very best (say a game like Lionheart), that wasn’t easy to beat - though I’d say a Super VGA enabled PC probably can outdo it, even though I’ve not seen examples of PC games like that from the era. So, it’s complicated 😅

[@stephenkennedy6358]

@@DutchRetroGuy I was referring to 2d. I realize the amiga lacks 3d.

[@Nebulous6]

I sold and supported PCs from 1989 to the 2000s. My recollection was that for 2D scrolling stuff (especially 8-way scrolling) the PC was struggling to do what the even the OCS Amiga (Amiga 1000, 500, 2000) could do, right up to 1991. Since that's your focus, I'll skip the comparisons of 3D for which the PC started to overtake the Amiga by around 1990 -- depending on the CPU accelerator an Amiga was outfitted with). Good examples of where the older 68000 CPU Amigas excelled would be games like Fly Harder, Cytron, Battlestorm, RoboCod, Odyssey, Lionheart, Project X, Assassin Special Edition, Hybris, and Zarathrusta. Even the first hardware-accelerated ATI cards (around 1990/1991) were having a very hard time doing smooth 8-way scrolling. I even had the pleasure of talking to one of the engineers at ATI. Guess what blitter they were trying to reverse engineer at the time?

[@amanloop]

another great vid m8!

[@DutchRetroGuy]

Thanks :)

[@musicaldude9429]

copper chunky - sliver light

[@axilmar254]

Very nice video! congratulations. Here is my question: Can higher resolutions be used in order to simulate smaller pixels? Can pixel lists be created on the fly from in-memory sprites that are not copied, but only their visible pixels are placed into copper lists? In this way, a screen could have tens or even hundreds of sprites, with many many colors. An algorithm would traverse pixels by the z coordinate (assuming z goes into the screen), and the top sprite's pixel would be put into the copper list; the display could be divided into a grid, and sprite stacks can exist on a grid basis, i.e. each rectangle on the grid would have its own sprite stack, thus not all sprites should be considered at once for every pixel. The algorithm that builds the copper list simply goes through the grid, and for each pixel it goes through the sprite stack, retrieving the pixel value from the top sprite, except if the pixel is transparent, then going to the next sprite etc. Sprites should be sized by powers of 2 so as that bit shifting can be used to find the appropriate pixel in each sprite. Or sprites could be made out of 8x8 or 16x16 pixel blocks. Sprites could have arrays of continuous pixels, so as that the CPU simply loops over the parts of the scanlines that are filled with data. The sprite data would be fixed in memory, so there would be no need to blit them to the screen. The reading of sprite pixels could be done by the cpu on fast ram, then create the copper list on chip ram at each frame. Double buffering could be setup so as that while the copper shows the current copper list, the cpu prepares the next copper list. Upon vblank, copper lists are swapped out. If this could be done quick enough by the cpu, and combined with palette changing, then theoretically the Amiga could do hundreds of sprites and scrolling layers with thousands of colors without the blitter. the 68000 is not that fast probably, but it would be interesting to see the practical limit of this approach.

[@DutchRetroGuy]

Thanks for your comment. I'll try to answer your questions. The first question: I'm afraid this technique can't be improved by changing resolution. The pixel size limitation is a consequence of the limits of the Copper (it can only change colours so fast), not the chosen resolution. In higher resolutions, the Copper would get fewer DMA slots, so you'd end up with fewer colour changes and bigger 'pixels'. You could perhaps create some form of mask to create the illusion of smaller pixels, but that would negatively impact visual quality in other ways. As for your second question, assuming I understood it correctly, that is essentially what I'm doing in the Free Form Sprite Layer video: all the background pixels there are pushed via Sprites, most of which have their pixels set directly through the Copper. This has drawbacks - it limits you to 4 colours because of Copper speed limitations, but you are free to set those pixels however you like (within the 2 bitplane limit). You are correct you can use this method to create 'infinite' sprites, but in reality this can be done much cheaper by just using the Blitter and/or CPU to change pixels in the existing bitplane setup. Sprite GFX aren't faster to change in memory than any other type of GFX, so you'd run out of speed quite quickly. The Amiga's Chip RAM bus is limited to 7 MB/second on the top end - and sadly this holds for changing Copperlists or Sprite data as well, so you'll always be limited. Regarding the colours, you can change colours with the Copper (or CPU), but the amounts you're talking about here can't be done on the Amiga HW. For one, you can only change 57,5 colours per scanline via the Copper at the absolute most, for another even if this limit didn't exist, you'd still be limited to the 7 MB/second speed limit on Chip RAM. Pushing thousands of colours in the way you're suggesting will sadly exceed that by a wide margin. However, it is possible - though extremely finicky and not at all practical in any sense of the word - to use the Copper and CPU together to change more colours per scanline. Doing so will obviously use up many/most of the CPU cycles in a scanline, so you're not going to be using this in animation or say a game, but it is possible. Theoretically, you can expect to roughly double the number of colours changed per scanline this way, but only if no bitplanes are displayed. If bitplanes are displayed, the CPU will start losing cycles because the bitplane/Copper combo will steal some/most/all of them and thus fewer colours can be changed. AGA would alleviate this to some degree, but even there you'd still be limited and in all practical sense this method would use so many CPU resources that anything other than static images becomes very questionable to achieve. Hope this answers some of your questions :)

[@axilmar254]

@@DutchRetroGuy Wow thanks for the quick reply! Really informative...

[@DutchRetroGuy]

@@axilmar254 you’re welcome 👍

[@Nebulous6]

This doesn't really answer your question. However, it does address the idea of a lot of animated objects on a scrolling screen with thousands of colors on screen at the same time using the older Amiga chipsets. The first is Amiga 500 compatible and the second is Amiga 1000 and 500 compatible: kzbin.info/www/bejne/gHvGq5ePhJ2BZ8U kzbin.info/www/bejne/jnXHfqKdodKImNU The author says that part of the secret is racing-the-beam techniques combined with HAM6.

[@Mute67]

Does this so called 7 bitplane mode work in high resolution mode i.e. 640x400/512?

[@DutchRetroGuy]

Good question, I don't know. I might have to test that out now ;) However, even if it does work in hires, it won't help effects like these as these effects are limited by the Copper and not the resolution of the screen.

[@Mute67]

@@DutchRetroGuy I'm just curious if it could be used in higher resolution. I've been tinkering with the copper in AMOS Pro to get more colours per scanline.

[@DutchRetroGuy]

@@Mute67 I tested this out because I really wanted to know and the change to the code is literally just one value. Sadly, it doesn't work. If you set 7 bitplanes and hires, the screen is just blank :(

[@Mute67]

@@DutchRetroGuy Ok interesting.. thank you for your answer :)

[@10shu]

very interesting...

[@itsdarklikehell]

AMIGAAAAA! godverdomme...

[@djaccount5458]

Nice channel

[@DutchRetroGuy]

Thanks :)

[@djaccount5458]

I started write mario kart in javascript. I need solve problem, how make procedure of drive opponents kart. Today i will go to bookstore. Maybe i will find a clue..

[@random_precision_software]

Is that python on the Amiga?

[@DutchRetroGuy]

No, I cross develop using my PC, so that is PyCharm on Windows 10. Technically there is nothing stopping you from running this on Amiga tough, assuming Python 3 and the modules I use are available on it.

[@random_precision_software]

@@DutchRetroGuy I don't know python I use C# now and C 30 years ago.. Borland Turbo C it was lol. Pity I can't use C# on the Amiga?

[@DutchRetroGuy]

@@random_precision_software I don't think there's C# for the Amiga, though I could be wrong.

[@fundi_mike]

Another alternative to the "pc" is to use python on the amiga.

[@DutchRetroGuy]

True, though the usefulness of cross-assembly is lost that way. Plus, the DMA timing issues are so much easier to find and fix using an emulator. I'd highly recommend using a PC/Mac as your Amiga development environment. You'll get stuff done a lot quicker and easier than sticking to original HW. That said, it's certainly possible to do all I did here on the Amiga itself. It's just not how I program these things ;)