Mandelbrot set

Mandelbrot set on FPGA, Part 2 – Modelling & First FPGA implementation

In the previous post, I introduced my idea of implementing the Mandelbrot set on an FPGA and described the Mandelbrot set equation and the Escape-time coloring algorithm. This post will talk about the implementation.


Modeling the Mandelbrot set

I consider it a good idea to start any FPGA implementation work with some planning, and in the case of an algorithm, the first thing you’d want to do is write a simple implementation of it yourself, just so you can verify that your understanding of the algorithm is correct. My implementation is a simple C program using double types, which outputs an image in the PPM format.

The implementation generally does the following:

  • sets up a palette for the image
  • writes the appropriate headers for the image
  • walks over all pixels of the output image
  • maps the current pixel coordinate into the mathematical Mandelbrot space
  • calculates the Mandelbrot set equation for up to maximum iterations, or until the value limit is reached
  • uses the number of iterations as an index into the RGB palette
  • writes the RGB values to the output image

Running this program will produce the following image:

Mandelbrot set

Mandelbrot set

Seems to work just fine!

Since floating-point data types are not really appropriate for FPGAs, you need to consider how to convert the floating-point arithmetic to integer arithmetic, or more specifically, to fixed-point arithmetic. Generally, this can be quite a tiresome step, since you need to carefully consider how many integer / fractional bits to use in each step, when to cut / round bits, weighing in hardware costs, etc.

Luckily, the Mandelbrot set calculation is relatively simple and limited in range, so you can basically eyeball the correct number of bits to use. My implementation is using a fixed point format s4.49 (s represents the single sign bit, the number 4 before the decimal point is the number of integer bits and the number 49 after the decimal point is the number of fractional bits).

For this algorithm, the most critical parts are before the decimal point – we need signed numbers, and we can eyeball the maximum value of the calculations to always be smaller than 16.0, so 4 integer bits are needed. The fractional part seems arbitrary and the reasoning will be explained a little later, but this number represents the precision of our calculations, which are important when zooming into the Mandelbrot set.

Another thing to consider is the maximum number of iterations for a single point. For the moment, I decided to go with 256 maximum iterations, mostly because that number nicely fits in an 8bit variable. But this decision is pretty much arbitrary, as the most appropriate number of iterations is hard to pinpoint. Maybe I’ll revisit this and implement some sort of dynamic approach according to the current ‘scene’ – position and zoom. For now, it should do.


FPGA implementation preparations

This is my first time working on the Terasic DE10-nano FPGA board, so some introductory research was needed. Terasic has a lot of documentation on all of its boards available on its site which is worth at least a cursory glance. The most useful one is the board schematic and their example projects.

From the schematic, you can see that the HDMI TX IC used is the Analog Devices’ ADV7513, and that is excellent since the interface to the FPGA TX is pretty much the same as the one for the ADV7123, which is used on a lot of FPGA boards for VGA analog output. The HDMI TX also requires some configuration through the I2C bus, I decided to just reuse the code from the sample HDMI sample project for this part.

Terasic also provides software to create the Quartus project for you, which is great, because manually editing pin constraints is not a fun exercise.

DE10-nano Systembuilder

DE10-nano Systembuilder

Of course, you’d want to first test any new FPGA board with the vendor-provided software – I tried the Linux running on the DE10-nano:

Linux running on the DE10-nano

Linux running on the DE10-nano

Another important document worth a glance is the FPGA device user manual, or in this case, the

. While an FPGA device is generally pretty configurable, there are some fixed blocks inside, which we’ll use generously.

One of the important ‘fixed’ blocks are the memory blocks. From the handbook, you can see that the memory blocks can be configured in 1k x 10 or 1k x 8 sizes, which will be used extensively in this project, as will be described later.

Another important block is the so-called DSP block, which is basically a multiplier with some additional logic. The most important property of the DSP block is the supported input operand width. From the handbook, you can see that a single DSP block supports up to 27×27 multiplier operands, and DSP blocks can be chained together. For better precision in the Mandelbrot calculations, I decided to use two DSP blocks for a single multiplication – this closely matches the precision of a double floating-point datatype on a PC and will provide solid Mandelbrot zooming. If you wondered where that number 49 in the selected fixed-point format (s4.49) above comes from, this is it – since the whole multiplier input is 54 bits, and we need to take into account the sign and integer parts, we can get a maximum of 49 fractional bits from the FPGA hardware.


FPGA implementation

Besides the basic scaffolding for the project, you’d usually want to get the clocks, PLLs, and resets working – all three can easily be tested with the Hello World of FPGAs – a LED blinky.


After that, some real work – the video sync generator, which is basically just a couple of counters and comparators – you need to count the video columns and rows and output an active signal together with horizontal and vertical sync signals. You can see my implementation here. If you output the counters from the video sync generator module, together with some helper signals, you can already generate a video output. See my version here, and the output below:

Sample HDMI output

Sample HDMI output

With the video sync signals working, it’s time to decide how to handle the actual pixels. Since the Mandelbrot set implementation has a limited number of iterations as its output, the logical choice is to use a color palette. That implies two sets of memories for the final pixel output – a video index RAM, which holds the palette index (and is basically just a number of iterations for that particular pixel), and a palette memory. The index RAM requires image_width x image_height entries that are 8bits wide and the palette memory then has 2^8 (256) entries and must be 24bits (8+8+8 for RGB) wide. You can see my implementation here.

I also wrote an implementation of a text console, since I wanted to put some textual information on the video output, like the current position & zoom, and the number of iterations and time required to render the whole screen. The text console is in a way similar to the normal pixel output, in that you have a character index RAM and a palette of sorts, in this case, a character ROM memory. What is different is how you access the pixels of the characters since you need to read the same character multiple times – font_width times horizontally, and font_height times vertically. You can see my implementation here, and the output of the console, and some color background below:

Video text console

Video text console

Mandelbrot set calculation

Mandelbrot set calculation can be thought of as consisting of two parts:

  • a location walker, which must go over all pixel coordinates and output the coordinates in mathematical space
  • an iteration calculator, which must calculate the number of iterations for each coordinate

These two parts strongly imply a sort of producer-consumer relation – since the coordinates can be calculated quickly and easily, once you figure out your initial position (upper left corner) and the step in horizontal and vertical directions (Mandelbrot set position and zoom), but the per-pixel iterations take a number of cycles on average. I split the Mandelbrot set calculations into a mandelbrot_coords module and a mandelbrot_calc module, with a FIFO in between.

The coordinate calculation is pretty easy, it basically boils down to a couple of adders:

always @ (posedge clk, posedge rst) begin
  if (rst) begin
    cnt_x   <= #1 VMINX;
    cnt_y   <= #1 VMINY;
    cnt_adr <= #1 'd0;
    cnt_en  <= #1 1'b1;
    man_x   <= #1 MAN_DEF_X0;
    man_y   <= #1 MAN_DEF_Y0;
  end else if (clk_en) begin
    if (init) begin
      cnt_x   <= #1 VMINX;
      cnt_y   <= #1 VMINY;
      cnt_adr <= #1 'd0;
      cnt_en  <= #1 1'b1;
      man_x   <= #1 MAN_DEF_X0;
      man_y   <= #1 MAN_DEF_Y0;
    end else if (out_rdy && cnt_en) begin
      if (cnt_x == VMAXX) begin
        if (cnt_y == VMAXY) begin
          cnt_en  <= #1 1'b0;
        end else begin
          cnt_y   <= #1 cnt_y +'d1;
          cnt_adr <= #1 cnt_adr +'d1;
          man_y   <= #1 man_y + inc_y;
          $display("Mandelbrot: processing line %d", man_y);
        cnt_x <= #1 VMINX;
        man_x <= #1 MAN_DEF_X0;
      end else begin
        cnt_x   <= #1 cnt_x + 'd1;
        cnt_adr <= #1 cnt_adr + 'd1;
        man_x   <= #1 man_x + inc_x;

I had a simulation/implementation mismatch here, which took a while to figure out – the problem is that Quartus can only do calculations with Verilog parameters with 32bit numbers, while the Icarus Verilog simulator seems to use larger datatypes (come on Intel, step up your game – Quartus seems really *really* dated compared to Vivado, this problem, really poor SystemVerilog support, … and this is coming from someone who always preferred Intel / Altera FPGAs …).

For the iteration calculation, the implementation is, again,  simple (deceptively so!):

assign xx_mul_comb  = x*x;
assign yy_mul_comb  = y*y;
assign xy_mul_comb  = x*y;
assign xx_comb      = xx_mul_comb[2*FPW-1-FP_S-FP_I:FPW-FP_S-FP_I];
assign yy_comb      = yy_mul_comb[2*FPW-1-FP_S-FP_I:FPW-FP_S-FP_I];
assign xy2_comb     = {xy_mul_comb[2*FPW-2-FP_S-FP_I:FPW-FP_S-FP_I], 1'b0};
assign limit        = {1'h0, 4'h4, {FP_F{1'h0}}}; // 4.0
assign niters_check = niters[IW+1-1:1] >= (MAXITERS-1);
assign limit_check  = (xx + yy) > limit;
assign check        = niters_check || limit_check;
assign x_comb       = xx - yy + x_man_r;
assign y_comb       = xy2 + y_man_r;

always @ (posedge clk) begin
  if (clk_en) begin
    if (in_vld && in_rdy) begin
      adr_o   <= #1 adr_i;
      x_man_r <= #1 x_man;
      y_man_r <= #1 y_man;
      x       <= #1 'd0;
      y       <= #1 'd0;
      xx      <= #1 'd0;
      yy      <= #1 'd0;
      xy2     <= #1 'd0;
      niters  <= #1 'd0;
    end else if(!check) begin
      x       <= #1 x_comb;
      y       <= #1 y_comb;
      xx      <= #1 xx_comb;
      yy      <= #1 yy_comb;
      xy2     <= #1 xy2_comb;
      niters  <= #1 niters + 'd1;

I was sure I’ll need to implement some sort of a state machine to handle initialization of the variables and the final check, but, by a lucky coincidence, this code works just fine – there is no need to delay the checking of x^2 + y^2 calculation, as the result starts from 0, so initially, it will always produce correct results.


Throwing all the code together will produce the following result:

Mandelbrot set on an FPGA

Mandelbrot set on an FPGA

So here it is, a Mandelbrot set calculated on an FPGA, in glorious 640×480 resolution with 27bit fixed-point precision! See all of my code in my mandelbrot_fpga project on Github, tagged with v0.4.


Next steps

With the initial version working, the project still needs some additions to make it better and more useful:

  • increasing the precision to 54bits – this was omitted since Quartus doesn’t like 64bit integers in parameters, and this needs to be handled slightly differently
  • moving the Mandelbrot calculations to a separate, faster clock – this was the point after all – speed! Currently, the ~25MHz video clock is used for all logic
  • multiplying the mandelbrot module to use up all available DSP elements of the (pretty generous) Cyclone V device on the DE10-nano board
  • better pipelining for the multipliers – a couple of registers need to be added, and a single calculation module updated to handle multiple coordinates at once
  • making the logic more configurable – currently, a lot of config is handled with params, which will need to be proper inputs
  • convert the project to be MiSTer-compatible
  • last but certainly not least – add the ability to actually zoom and move around the Mandelbrot set – I’ll probably just add a soft-core CPU to handle this part, with inputs from keyboard/joypad


Stay tuned for the next post!


Beautiful graphics from simple math – Mandelbrot set on FPGA, Part 1

Introduction to the Mandelbrot set

Like I mentioned in the previous post, I wanted to familiarize myself with the HDMI output on the DE10-nano FPGA board, and there is no harm in getting some pretty graphics along the way, so I decided to implement a Mandelbrot set viewer on FPGA.

If you are not familiar with the Mandelbrot set, it is a type of a fractal, which is simply put an infinitely – repeating recursive pattern. That means that you can zoom into the set and discover ever repeating, self-mirroring patterns. They are also a little weird ;). You can read more about them on the linked Wikipedia article.

The familiar look of the Mandelbrot set is depicted in this picture:

Mandelbrot set

Mandelbrot set

For the formal definition of the Mandelbrot set, I’ll just quote the Wikipedia article:

The Mandelbrot set is the set of values of c in the complex plane for which the orbit of critical point z= 0 under iteration of the quadratic map  remains bounded. Thus, a complex number c is a member of the Mandelbrot set if, when starting with z0 = 0 and applying the iteration repeatedly, the absolute value of zn remains bounded for all n > 0.

For example, for c = 1, the sequence is 0, 1, 2, 5, 26, …, which tends to infinity, so 1 is not an element of the Mandelbrot set. On the other hand, for c = −1, the sequence is 0, −1, 0, −1, 0, …, which is bounded, so −1 does belong to the set.

Which put in simple terms means that the Mandelbrot set can be calculated simply by iteratively calculating the equation for all “interesting” complex numbers , and starting the iteration with . The complex number is expressed as x + iy, where x and y can be mapped to the horizontal and vertical position on the screen. If the iteration doesn’t escape to infinity, then is part of the set.

That handles the “black&white” part. You can then decide how to color the image. A popular (and simple) algorithm you can use is the Escape time algorithm, which selects the color of each individual pixel based on whether the pixel is part of the set or not, and if not, how many iterations it took to “escape”.

The simplified Escape time algorithm can be represented in pseudocode like this:

x2 := 0
y2 := 0

while (x2 + y2 ≤ 4 and iteration < max_iteration) do
  y := 2 × x × y + y0
  x := x2 - y2 + x0
  x2 := x × x
  y2 := y × y
  iteration := iteration + 1

The Mandelbrot set colored with the Escape time algorithm has some properties that are very helpful if you want to calculate it on an FPGA:

  • the set is closed and contained in a closed disk of radius 2 – if the distance from the origin (starting point) is bigger than 2 for the current iteration, then that origin is not part of the set, and you can stop iterating
  • since the set has a limited radius, that means that the range of numbers we need to work with is also limited – important if you want to use integer only math
  • the pixel values are independent of one another – you can calculate all pixels in parallel
  • not a lot of iterations are needed for each pixel
  • the equation to calculate it is simple, probably the simplest of all fractals that I know of


So, to implement the algorithm on an FPGA, you can already see the requirements:

  • memory to hold the calculated pixel values – how much depends on the FPGA resources, and the amount of available memory will determine the maximum resolution
  • the maximum number of iterations will be also limited by the memory – using 8, 9 or 10 bit memory width will provide the best resource utilization
  • as can be seen from the pseudocode above, a lot of multipliers will be needed, ideally, you would use all the FPGA DSP elements available
  • the multipliers will need to be quite wide, at least 27 bits, since you’d want to zoom deep into the Mandelbrot set


This covers the introduction to the Mandelbrot set. I’ll go deeper into the implementation in the next post. Cheers!


The BoingBall, Part 2

So, we have rendered frames of our BoingBall, as described in Part 1. What you want to do next is check if the animation is seamless – that is, if it loops without glitches. Best way is to convert the frames into a .gif or .avi animation (in my experience GIF works better) with your favorite photo / video editor. You will also need to reduce the number of colors of your frames, I used just two colors (white & red) + background. I needed a few tries to get this right:

BoingBall animation

Once the animation looks good, you need to first decide on what kind of Amiga resolution the animation will be shown – either hires or lores. The difference is that on hires the pixels are not square, but are twice as high as they are long, so you need to ‘squash’ the ball vertically:


Now you need to somehow convert the animation data to be used on the Amiga. You have to remember that contrary to PCs of today which use so called ‘chunky‘ pixels, Amiga uses a planar graphics display, which splits each bit of the pixel data into a separate plane – that allows it to save memory & bandwidth, if for example you only needed two colors you would only require one bit per pixel instead of 8 (or even 16 or 32!).

For the conversion, I wrote a simple Python script which takes a GIF animation, splits it into frames, splits the frames into bitplanes and writes the result into a source file that can be used in AsmOne assembler on the Amiga. The script is attached bellow.

I also made a minimig logo, which you can see below:

Minimig logo

Now comes the fun part – writing a program that will show this animation on the Amiga – or in this case, the Minimig board. We want this animation to work very early in the Minimig bootup, when no operating system is available, actually even the CPU is not available as it is in reset.

Luckily, hitting the hardware registers directly is nothing special on the Amiga as everyone was (is!) doing it, from demo coders (check out the Amiga Demoscene Archive for some amazing demos) to games. The Amiga chipset is quite complex, so I won’t go into too much details about how to set it up. If you want some great tutorials about writing hardware-hitting Amiga software, you might want to check out Photon’s great coding page and Youtube channel, it was certainly a great help for me to freshen up my Amiga coding 😉

So, we have no OS and no CPU, how can we play an animation? Well, the custom chips of the Amiga will help here. Amiga has some very interesting hardware, but for this animation we are interested in two particularly: the Blitter and the Copper. The Blitter’s name comes from Blit, which is short for block image transfer. Simply put, the Blitter is a configurable DMA engine that can transfer images in memory (it is much more capable, but let’s leave it at that). The Copper, short for co-processor, is a very basic processor that only has three commands: MOVE, WAIT and SKIP, but it is also tied to the video beam. Since the Copper can write Blitter’s registers, they together form a sort of a Turing-complete system, certainly capable enough to play back this animation.

Since you don’t want to write this ‘blind’, you need a way to test that everything works while you’re working on it. I used ASMOne, which is a great assembler for the Amiga, and WinUAE, a windows Amiga emulator. Our program is using the CPU to set up the custom chipset, and once set up, the chipset runs by itself. The CPU part will be replaced with custom code on the minimig, since on minimig the control CPU can write custom registers when the CPU is in reset. For the test program, we need a little more setup than is required for minimig, especially saving enabled interrupts and DMAs, which are restored on exit. The CPU must also copy the minimig logo and the boingball animation data to the proper place in chipram, then it enters a loop waiting for the mouse button press, cleans up and exits. The required part is setting up bitplane DMAs, copper, screen, blitter and the color values:

 move.w #$0000,$dff1fc ; FMODE, slow fetch mode for AGA compatibility
 move.w #$0002,$dff02e ; COPCON, enable danger mode
 move.l #Copper1,$dff080 ; COP1LCH, copper 1 pointer
 move.l #Copper2,$dff084 ; CPO2LCH, copper 2 pointer
 move.w #$0000,$dff088 ; COPJMP1, restart copper at location 1
 move.w #$2c81,$dff08e ; DIWSTRT, screen upper left corner
 move.w #$f4c1,$dff090 ; DIWSTOP, screen lower right corner
 move.w #$003c,$dff092 ; DDFSTRT, display data fetch start
 move.w #$00d4,$dff094 ; DDFSTOP, display data fetch stop
 ;move.w #$7fff,$dff096 ; DMACON, disable all DMAs
 move.w #$87c0,$dff096 ; DMACON, enable important bits
 move.w #$0000,$dff098 ; CLXCON, TODO
 move.w #$7fff,$dff09a ; INTENA, disable all interrupts
 move.w #$7fff,$dff09c ; INTREQ, disable all interrupts
 move.w #$0000,$dff09e ; ADKCON, TODO
 move.w #$a200,$dff100 ; BPLCON0, two bitplanes & colorburst enabled
 move.w #$0000,$dff102 ; BPLCON1, bitplane control scroll value
 move.w #$0000,$dff104 ; BPLCON2, misc bitplane bits
 move.w #$0000,$dff106 ; BPLCON3, TODO
 move.w #$0000,$dff108 ; BPL1MOD, bitplane modulo for odd planes
 move.w #$0000,$dff10a ; BPL2MOD, bitplane modulo for even planes
 move.w #$09f0,$dff040 ; BLTCON0
 move.w #$0000,$dff042 ; BLTCON1
 move.w #$ffff,$dff044 ; BLTAFWM, blitter first word mask for srcA
 move.w #$ffff,$dff046 ; BLTALWM, blitter last word mask for srcA
 move.w #$0000,$dff064 ; BLTAMOD
 move.w #BLITS,$dff066 ; BLTDMOD
 move.w #$0000,$dff180 ; COLOR00
 move.w #$0aaa,$dff182 ; COLOR01
 move.w #$0a00,$dff184 ; COLOR02
 move.w #$0000,$dff186 ; COLOR03
 move.w #(bpl1>>16)&$ffff,$dff0e0 ; BPL1PTH
 move.w #bpl1&$ffff,$dff0e2 ; BPL1PTL
 move.w #(bpl2>>16)&$ffff,$dff0e4 ; BPL2PTH
 move.w #bpl2&$ffff,$dff0e6 ; BPL2PTL

We set up the space for the bitplanes at $80000:

 ORG $80000
 dcb.b BPLSIZE
 dcb.b BPLSIZE

Most of the work is done with the copper and blitter. Since the minimig logo is fixed in place, it only needs moving to the proper position in the bitplanes. The rotating ball is also not moving around, so there is no need to clear the bitplanes, we just write new data over the old one. If we want to show the boingball animation with the correct speed, one frame of the animation must be shown for 5 minimig frames (minimig has a refresh rate of 50Hz for PAL). That means quite a long copper list, moving the copper pointer around each frame and the blitter pointer every five frames, since we don’t have a CPU to do any of that. Below is copper code for a single frame of animation, spanning 5 Amiga screen refreshes:

 dc.w $0050,(f0p0>>16)&$ffff
 dc.w $0052,(f0p0)&$ffff
 dc.w $0054,((bpl1+BALLOFF)>>16)&$ffff
 dc.w $0056,((bpl1+BALLOFF))&$ffff
 dc.w $0058,(BLITH<<6+BLITW)
 dc.w $0107,$7ffe
 dc.w $0050,(f0p1>>16)&$ffff
 dc.w $0052,(f0p1)&$ffff
 dc.w $0054,((bpl2+BALLOFF)>>16)&$ffff
 dc.w $0056,((bpl2+BALLOFF))&$ffff
 dc.w $0058,(BLITH<<6+BLITW)
 dc.w $0084,(c2f01>>16)&$ffff
 dc.w $0086,(c2f01)&$ffff
 dc.w $ffff,$fffe
 dc.w $0084,(c2f02>>16)&$ffff
 dc.w $0086,(c2f02)&$ffff
 dc.w $ffff,$fffe
 dc.w $0084,(c2f03>>16)&$ffff
 dc.w $0086,(c2f03)&$ffff
 dc.w $ffff,$fffe
 dc.w $0084,(c2f04>>16)&$ffff
 dc.w $0086,(c2f04)&$ffff
 dc.w $ffff,$fffe
 dc.w $0084,(c2f10>>16)&$ffff
 dc.w $0086,(c2f10)&$ffff
 dc.w $ffff,$fffe

This code is repeated eight times for each frame of the animation.

So, after these two long posts, does it work at all? It sure does:

Whole AsmOne source code is here:

The BoingBall, Part 1

I’ve received some questions about how I made the new minimig logo with the rotating checkered ball, so I thought I’d write something about it for my first post.

The BoingBall is quite famous in the Amiga land, as it was featured in one of the first demos made for the Amiga computer to demonstrate its capabilities at the Consumer Electronics Show in January 1984. It was later used as an official logo of the Amiga. Its roots go even further back, but enough with history. You can watch this video describing how the BoingBall demo came about:

At the time I was replacing the boot code in minimig, and I thought ‘why not add something more dynamic to the boot screen?’ So the idea to use the iconic BoingBall animation was born.

When I was younger, I played around with 3D animation and modeling a lot, mostly with Lightwave on the Amiga and later with 3D Studio running in DOS on a PC. But for this task, a much simpler renderer was used, one that is probably best suited for this task, also one of my favourites – the freely-available POV-Ray. POV-Ray doesn’t have a modeler, you describe the scene in a text file, but for such a simple scene, you wouldn’t need a full-featured modeler anyway.

I won’t go into all the features of POV-Ray language, I’ll just describe the basics needed for the BoingBall animaton. You need three things in a basic scene like this:

  • an object to render
  • a camera, preferably looking at your object
  • lights

You place the camera with a location and a direction statement :

  location <0,0,-6>
  look_at <0,0,0>

Next, lights – I used both ambient and omni lights around the ball:

global_settings { ambient_light color White }
light_source { <+0, +0, -6> color White }
light_source { <+0, +0, +6> color White }
light_source { <+0, -6, +0> color White }
light_source { <+0, +6, +0> color White }
light_source { <-6, +0, +0> color White }
light_source { <+6, +0, +0> color White }

And then comes the object of interest – a sphere with a red-white checkered pattern:

sphere {
  // placement and size
  <0, 0, 0>, 2
  // texture
  texture {
    pigment {
      // red / white checker pattern
      checker color Red, color White

The sphere’s texture needed some fixing of the scale and a warp pattern modifier that wraps the checkered pattern around a sphere:

      // the x-y scaling is a bit off, fixing it together with size
      scale <1.5/pi, 1.0/pi, 1>*0.25
      warp { spherical orientation y dist_exp 1 }

All that is needed now is the animation:

  // rotate (rotate after texture!)
  // 1/8th of full rotation so the texture aligns for a nice animation
  // adding a slight tilt (after animation rotation!)
  rotate <0,0,-15>

The order of these steps is important in this case – first you apply the texture, than the rotation and the slight tilt the last, otherwise the result will not be what you desired. The clock in the last code snippet is the animation parameter (for a repeating animation you need to calculate how much the ball must rotate in a desired number of frames).

To render this scene, you give POV-Ray some parameters, preferably in an .ini file:

Cyclic_Animation = on

And the result:


Once you have all of the frames of the animation, you need to parse the image data, transfer it to the Amiga and write a copper list to animate it (yes, the boot logo doesn’t use the CPU, the animation runs using blitter and copper only). But that is a story for another post.


Continued in BoingBall, Part 2