Glad to see you are keeping the Amiga alive! I still have my Amiga 2000HD from the 80s, with 68060 accelerator, Emplant board, Picasso II board, Opalvision board, and GVP Time Base Correction/Frame Grabber board.
Cool setup. I still have both my Amiga’s from back then (and an A600 as well for good measure), but even now they’re nowhere near that spec. I have an A500 with ACA500+ and an A1200 with a Blizzard 1230MK IV, both with scandoubler and the A1200 also has a Rapidroad USB controller in there, which makes file transfer really easy!
Thanks! I actually already did a video on sprite re-use (kind of, it depends on what kind of re-use you're talking about here). It's about a sprite based background without limits on pattern width: ua-cam.com/video/rzFUq1tHPHc/v-deo.html
The Blitter in the A1200 is the same as the one in the A500. However, due to the AGA chipset being more efficient at displaying the screen, it still gets more cycles per frame and thus appears to be faster. AGA Sprites are improved over their A500 counterparts. Where the A500 was limited to Sprites that were 16 pixels wide, the A1200 could display Sprites at up to 64 pixels wide each. The A1200 also can choose which 16 colour bank(s) of colours to use for Sprites, meaning that in 32-128 colours the Sprites can have separate colours from the main screen, unlike the A500 where this was only possible if the screen used 16 or fewer colours. The Chipset still runs at 3.5MHz, though both the CPU, bitplanes and Sprites can now access memory in more than 16 bit chunks.
Pretty sure that on Amiga 500 you could get a speed-up if CPU was used for simpler things such as clearing/restoring background. I.e. when you are restoring the previous blits off the background you can use blitter and CPU together to gain some performance.
On A500 clearing with the CPU and Blitter together is indeed quite a bit faster, but copy operations (i.e. restoring the background) are always slower than the Blitter if the CPU is also involved. This is due to the fact the CPU has overhead in reading the instructions (and reading/decoding additional word(s) for the address to use), which the Blitter does not have. Since both the CPU and the Blitter access memory 16 bits at a time and the CPU can’t use all DMA slots while the Blitter can.
Thanks for the info, I appreciate it. It's been so many years since I coded on A500, so it's quite possible the speed up was for clearing only.@@DutchRetroGuy
Cookiecut is usually needed for bobs in games, which is why I used it. The bobs are 32x32 on a six bitplane screen. I suspect the difference in speed is probably due to not needing cookiecut in your demo. If you can get away with just doing copy blits, you get a lot more bobs on screen.
@@kjetilhvalstrand1009 screen setup is handled by the Copper. The CPU_Blit_Assist.asm file starts the Copper on lines 155-158 (; Activate copper list). The Copper list itself can be found in Data/copperlist.asm and contains all custom chip set writes required for the screen setup - apart from a write to BPLCON3 to set AGA/ECS features, IIRC. Several routines are called to fill in the missing palette and pointer values. These are called in CPU_Blit_Assist.asm from lines 102-110 (; Fill in missing parts of initial copper list).
THank you for this inspiring video. I've been struggling with AGA bobs and sprites lately. A1200 with or without fast-mem brings more solutions. Hope to see you at Revision 2020. Give us a lecture, will you? ;)
Thanks for the compliment! The A1200 is indeed a noticeable step up over the A500, though I will always love the OCS chipset :) Sadly, I won't be at Revision 2020 so no lectures here :(
AdamoLOL1 that does sound probable yes. It’s annoying, but I do think it’s probably better to be safe rather than sorry in this case. Hopefully it will only be a delay and still end up great for those who go!
Thanks, I'm pretty happy with the results. Though I'm also not certain this is as good as it can get. I have a hunch it may be possible to do better, but I had to release this eventually and not keep tinkering forever :)
From what i have read on stock a1200 when you set only 4 bitplanes it runs much faster than when using more bitplanes. It is something connected with bizzare memory interface aga has.
Via experiments I discovered that Fmode makes rather big difference on AGA. even 8 bitplanes with fmode 3 doesn't jam the machine as it would on "ocs" (fmode 0) mode.
@@CrazyArtEducator yes indeed, FMODE makes a pretty big difference. My code runs in FMODE 3 (4x fetch) already. It would lose a few bobs per frame if it ran in FMODE 0 (1x fetch). However, as I understood the original poster's comment he was not talking about FMODE but rather 4 bitplane mode by itself. Do note that I've not been able to verify his point for myself, though.
Hmmm.... I think in real world you would rather use the CPU to do some calculations and controlling, wouldn't you? In that case, one thing you could to to speed things up is to interleave the processing... not first doing all the calculation and then all the blitting, but take care that the CPU doesn't wait for the blitter, but does other things while the blitter is working.
Certainly that is an option. However, one of the reasons I made this is that discussions I had and saw on EAB about the topic of keeping the CPU busy while blitting usually ended with developers pointing out it was difficult to do that because in most ‘real world’ cases you tend to do the blitting in sequence rather than having other things to do. At any rate it’s certainly correct that (especially on AGA) keeping the CPU running while the Blitter is busy is a good tactic. This is just one way to do this, you can do it in many ways.
Exactly. I used to a crap load of stuff whilst the blitter was blitting. I'm not sure how big his bobs were, but I'm pretty sure I could do a lot more than 19 and did a load more than that in my earlier demos.
@@thewelder3538 I would like to point out that blitting 19 bobs using a standard cookiecut + copy for restore algorithm at 32x32 pixels in 6 bitplanes is the equivalent of blitting 131328 bytes per frame or ~6,26MB/second . The Blitter’s theoretical bandwidth (which you never actually can get, you lose quite a few bytes per second for bitplane DMA and CPU overhead) is ~6,78MB/second. Unless you either lower number of bitplanes or use a different blitting algorithm (which will make your blitting code less generally useful unlike mine here) you will not get as many bobs as I show here by just using the Blitter. The overhead cost of bitplane DMA and CPU will eat into that number, resulting in fewer bobs. This is shown in the program I show here by the way, just set it to ‘Blitter only’ and you’ll see the number drop.
@@DutchRetroGuy Okay that's true, but in 6 on an OCS machine wouldn't mean you're blitting in half-bright, on an AGA you'd be blitting 64 colour bobs. I'm not sure why anyone would do that for 32x32 pixel bob. On AGA, that would give you only 4 colours for any background you're blitting over. I'm actually more interested in the way you're erasing the bobs. I assume you're using the blitter shift register? Also, depending on how you're doing the bobs, I'd also be using the scroll registers and repointing the bitplanes down the screen to duplicate bobs already blitted. These are like classic demo effects.
@@thewelder3538 the amount of bitplanes the bob uses has no relevance for the number of colours left for the background, both use the same 6 bitplanes and thus share 64 colours between them. This is also why I use cookiecut mode for blitting. I restore by blitting the rectangle the bob takes up back from a pristine copy of the background graphics. Perhaps the problem here is misunderstanding what I'm doing - this video isn't meant to show the maximum number of bobs you could draw using methods like you've used in demos where you have full control over the entire scene. Nor am I trying to show what the gain can be if you separate the bob layer from the GFX layer. (mind you, those might be interesting ideas for later videos) Instead, it is an experiment in drawing bobs with the CPU and Blitter that is compatible with the way most games have their display set up. This means things like the bobs sharing their playfield with other graphics which have to stay in place and can have any shape, that the bobs can have any shape at any time, can freely overlap, can be in places the coder can't know ahead of time and leave the rest of the background/foreground in tact. Naturally, if I drop some or all of these requirements, all sorts of additional tricks become possible to increase the number of bobs processed ;)
Glad to see you are keeping the Amiga alive! I still have my Amiga 2000HD from the 80s, with 68060 accelerator, Emplant board, Picasso II board, Opalvision board, and GVP Time Base Correction/Frame Grabber board.
Cool setup. I still have both my Amiga’s from back then (and an A600 as well for good measure), but even now they’re nowhere near that spec. I have an A500 with ACA500+ and an A1200 with a Blizzard 1230MK IV, both with scandoubler and the A1200 also has a Rapidroad USB controller in there, which makes file transfer really easy!
Impressive, I didn't think the amiga could move that much around at 6bpl. Looking forward to more of your videos!
Thanks!
I have that same T-Shirt. I got it back in the Amiga Inc. days when they sold $50 coupons instead of computers.
Yeah, that's how I got it too. Part of me is amazed they even shipped it to me.
Excellent video! Explanation, music and production was superb. I hope more people will watch this and make use of you findings.
Thanks! I also hope people will implement this idea, it's basically "free" performance :)
Only just found this, but Fantastic video !
Thanks!
GREAT video and explanation sir !
I don't need any of this, but this is very interesting.
Very nice... sprite re-use was also a technique some games and demos had - maybe something to think about too, cheers!
Thanks! I actually already did a video on sprite re-use (kind of, it depends on what kind of re-use you're talking about here). It's about a sprite based background without limits on pattern width: ua-cam.com/video/rzFUq1tHPHc/v-deo.html
Great video. I'm going to look up more of your videos. Please do some A500 videos if you haven't already
Thanks!
I did do several other Amiga Tech videos, all of which do target the A500. Enjoy :)
An excellent video. How many bit planes are being used in this demo? At a guess, I'd say five - but it's not easy to tell...
Thanks for your comment!
The demo uses six bitplanes.
@@DutchRetroGuy Ah, okay - thanks very much!
What about Blitter & spites in Amiga 1200? Was the same chips like in Amiga 500 or with more possibilities ? What about clock ?
The Blitter in the A1200 is the same as the one in the A500. However, due to the AGA chipset being more efficient at displaying the screen, it still gets more cycles per frame and thus appears to be faster.
AGA Sprites are improved over their A500 counterparts. Where the A500 was limited to Sprites that were 16 pixels wide, the A1200 could display Sprites at up to 64 pixels wide each. The A1200 also can choose which 16 colour bank(s) of colours to use for Sprites, meaning that in 32-128 colours the Sprites can have separate colours from the main screen, unlike the A500 where this was only possible if the screen used 16 or fewer colours.
The Chipset still runs at 3.5MHz, though both the CPU, bitplanes and Sprites can now access memory in more than 16 bit chunks.
@@DutchRetroGuy THX for quick answer with good explain.
Awesome content!
Thanks!
Very interesting....thank you
Pretty sure that on Amiga 500 you could get a speed-up if CPU was used for simpler things such as clearing/restoring background. I.e. when you are restoring the previous blits off the background you can use blitter and CPU together to gain some performance.
On A500 clearing with the CPU and Blitter together is indeed quite a bit faster, but copy operations (i.e. restoring the background) are always slower than the Blitter if the CPU is also involved.
This is due to the fact the CPU has overhead in reading the instructions (and reading/decoding additional word(s) for the address to use), which the Blitter does not have. Since both the CPU and the Blitter access memory 16 bits at a time and the CPU can’t use all DMA slots while the Blitter can.
Thanks for the info, I appreciate it. It's been so many years since I coded on A500, so it's quite possible the speed up was for clearing only.@@DutchRetroGuy
How big are your bobs? 19 seems REALLY low. I had 30 in my demo, but I don't use something as slow as a cookie cut.
Cookiecut is usually needed for bobs in games, which is why I used it. The bobs are 32x32 on a six bitplane screen. I suspect the difference in speed is probably due to not needing cookiecut in your demo. If you can get away with just doing copy blits, you get a lot more bobs on screen.
Just the video I need.. for my chipset.library
I aim to please :P
@@DutchRetroGuy I setup a git repo, in your copyright notice, it says “ME” who is me?
github.com/khval/CPU-Blit-Assist
@@DutchRetroGuy A question where is the screen setup in this tutorial?
@@kjetilhvalstrand1009 my Copyright notice does contain my name. It's right there on the front page of your github repo ;)
@@kjetilhvalstrand1009 screen setup is handled by the Copper. The CPU_Blit_Assist.asm file starts the Copper on lines 155-158 (; Activate copper list).
The Copper list itself can be found in Data/copperlist.asm and contains all custom chip set writes required for the screen setup - apart from a write to BPLCON3 to set AGA/ECS features, IIRC.
Several routines are called to fill in the missing palette and pointer values. These are called in CPU_Blit_Assist.asm from lines 102-110 (; Fill in missing parts of initial copper list).
THank you for this inspiring video. I've been struggling with AGA bobs and sprites lately. A1200 with or without fast-mem brings more solutions. Hope to see you at Revision 2020. Give us a lecture, will you? ;)
Thanks for the compliment!
The A1200 is indeed a noticeable step up over the A500, though I will always love the OCS chipset :)
Sadly, I won't be at Revision 2020 so no lectures here :(
@@DutchRetroGuy considering the situation i think there wont be Revision this year or it will be seriously delayed,
AdamoLOL1 that does sound probable yes. It’s annoying, but I do think it’s probably better to be safe rather than sorry in this case.
Hopefully it will only be a delay and still end up great for those who go!
Very neat. 113% increase is nothing to sniff at.
Thanks, I'm pretty happy with the results. Though I'm also not certain this is as good as it can get. I have a hunch it may be possible to do better, but I had to release this eventually and not keep tinkering forever :)
It's shame there's no "love" button; like will have to suffice.
Thanks 😎
From what i have read on stock a1200 when you set only 4 bitplanes it runs much faster than when using more bitplanes. It is something connected with bizzare memory interface aga has.
Interesting. I've not noticed any such thing myself, but I suppose it could be possible. Strange stuff!
Via experiments I discovered that Fmode makes rather big difference on AGA. even 8 bitplanes with fmode 3 doesn't jam the machine as it would on "ocs" (fmode 0) mode.
@@CrazyArtEducator yes indeed, FMODE makes a pretty big difference. My code runs in FMODE 3 (4x fetch) already. It would lose a few bobs per frame if it ran in FMODE 0 (1x fetch).
However, as I understood the original poster's comment he was not talking about FMODE but rather 4 bitplane mode by itself. Do note that I've not been able to verify his point for myself, though.
Hmmm.... I think in real world you would rather use the CPU to do some calculations and controlling, wouldn't you? In that case, one thing you could to to speed things up is to interleave the processing... not first doing all the calculation and then all the blitting, but take care that the CPU doesn't wait for the blitter, but does other things while the blitter is working.
Certainly that is an option. However, one of the reasons I made this is that discussions I had and saw on EAB about the topic of keeping the CPU busy while blitting usually ended with developers pointing out it was difficult to do that because in most ‘real world’ cases you tend to do the blitting in sequence rather than having other things to do.
At any rate it’s certainly correct that (especially on AGA) keeping the CPU running while the Blitter is busy is a good tactic. This is just one way to do this, you can do it in many ways.
Exactly. I used to a crap load of stuff whilst the blitter was blitting. I'm not sure how big his bobs were, but I'm pretty sure I could do a lot more than 19 and did a load more than that in my earlier demos.
@@thewelder3538 I would like to point out that blitting 19 bobs using a standard cookiecut + copy for restore algorithm at 32x32 pixels in 6 bitplanes is the equivalent of blitting 131328 bytes per frame or ~6,26MB/second . The Blitter’s theoretical bandwidth (which you never actually can get, you lose quite a few bytes per second for bitplane DMA and CPU overhead) is ~6,78MB/second.
Unless you either lower number of bitplanes or use a different blitting algorithm (which will make your blitting code less generally useful unlike mine here) you will not get as many bobs as I show here by just using the Blitter. The overhead cost of bitplane DMA and CPU will eat into that number, resulting in fewer bobs. This is shown in the program I show here by the way, just set it to ‘Blitter only’ and you’ll see the number drop.
@@DutchRetroGuy Okay that's true, but in 6 on an OCS machine wouldn't mean you're blitting in half-bright, on an AGA you'd be blitting 64 colour bobs. I'm not sure why anyone would do that for 32x32 pixel bob. On AGA, that would give you only 4 colours for any background you're blitting over. I'm actually more interested in the way you're erasing the bobs. I assume you're using the blitter shift register? Also, depending on how you're doing the bobs, I'd also be using the scroll registers and repointing the bitplanes down the screen to duplicate bobs already blitted.
These are like classic demo effects.
@@thewelder3538 the amount of bitplanes the bob uses has no relevance for the number of colours left for the background, both use the same 6 bitplanes and thus share 64 colours between them. This is also why I use cookiecut mode for blitting.
I restore by blitting the rectangle the bob takes up back from a pristine copy of the background graphics.
Perhaps the problem here is misunderstanding what I'm doing - this video isn't meant to show the maximum number of bobs you could draw using methods like you've used in demos where you have full control over the entire scene. Nor am I trying to show what the gain can be if you separate the bob layer from the GFX layer.
(mind you, those might be interesting ideas for later videos)
Instead, it is an experiment in drawing bobs with the CPU and Blitter that is compatible with the way most games have their display set up.
This means things like the bobs sharing their playfield with other graphics which have to stay in place and can have any shape, that the bobs can have any shape at any time, can freely overlap, can be in places the coder can't know ahead of time and leave the rest of the background/foreground in tact.
Naturally, if I drop some or all of these requirements, all sorts of additional tricks become possible to increase the number of bobs processed ;)