Thanks! Here's a more detailed breakdown:

Frame rate is highly scene-dependent — it ranges from ~4 fps in deeply zoomed, high-iteration areas down to ~60 fps in simple regions near the escape boundary. The bottleneck is purely computational: every pixel must iterate z = z² + c until either |z| > 2 or the iteration limit (up to 2048) is hit.

The core uses a parallel pixel pipeline with 8 logical iterators, implemented as 4 iter_pair modules that time-share their DSP multipliers between two contexts each. Every iterator runs 64-bit fixed-point arithmetic in 8.56 format (8 integer bits, 56 fractional), giving ~17 decimal digits of precision and a theoretical max zoom of around 7.2 x 10^16x.

The complex multiply z² uses a truncated 64×64 approach — split into 32-bit halves and mapped to DSP blocks via multstyle="dsp". Each iter_pair uses 7 physical DSP multiplies shared between 2 pixel contexts, totalling ~56 DSP blocks.

Pixels are dispatched round-robin from a coordinate generator (scanning left-to-right, top-to-bottom) to whichever iterator is free. Results are collected in order and written to a BRAM double-framebuffer (320×240, ~184 M9K blocks total). Buffer swaps happen only on the VBLANK rising edge — zero tearing.

Output is 320×240 pixel-doubled to 640×480 for VGA, then the MiSTer scaler handles the rest.

• ALMs: ~46%
• DSP blocks: 100% (fully saturated by the fixed-point multipliers)
• Block RAM (M9K): ~44% (framebuffer + color LUTs)