View Single Post
Old 07 April 2019, 02:01   #1
Posts: n/a
Driving blitter from copper

I've been doing a bit of Amiga hacking recently and, having hit a bit of a motivation trough, thought I'd share where I've got to in the hope of getting a bit of feedback/constructive criticism.

My goal has been to explore how much performance I can squeeze out of the baseline OCS/ECS hardware, compared to what I could do as a teenager back in the 1990s. My sample application is a simple 50Hz horizontally scrolling platform game, using some old graphic assets I had to hand (credit to Nick Lee for those). Although the assets don't really require it, I'm running in EHB mode to make things a bit more challenging from a bandwidth perspective.

The approach I've been pursuing (and I know this has been done before in various ways) is to use the copper to perform all writes to blitter registers: where normally during frame n I would have directly controlled the blitter to generate the contents of frame n+1, instead I am writing a copper list to run during frame n+1 to generate frame n+2.

I like this approach, because if I run in blitter nice mode, then while there is work for it to do the blitter will soak up any spare cycles left by the 68k. This is efficient, and means that our goal in writing software becomes solely to reduce instruction fetch bandwidth. So for example:

mulu #33,d5

always beats:

move.w d5,d6
lsl.w #5,d5
add.w d6,d5

A source tarball is here:

If you'd like a quick look at the game, I've also built it as a replacement A600 Kickstart ROM.

Release version is here:
Debug version is here:

The debug version has some visualisation aids to help with optimisation. It prints the scanline at which the "worst" frame so far encountered completed both its CPU and blitter work, and shows a pair of stacked bar charts at the left of the screen.

The left-hand bar chart has colors for the various phases of CPU work:
  • cyan: erase dirty rectangles
  • magenta: update edges for scroll
  • yellow: run player and boomerang
  • red: run game objects
  • green: CPU idle
Remember, when we say "erase dirty rectangles" we actually mean "write copper list to erase dirty rectangles".

The right-hand bar chart simply displays blue for blitter busy and red for blitter idle.

Code is a bit of a mess at the moment, but should be fairly self-explanatory. As I say, feedback is very welcome.

Last edited by ebenupton; 08 April 2019 at 00:01.
Page generated in 0.04114 seconds with 11 queries