While testing my Coppenheimer update (still in progress), I loaded up ProTracker for testing. I started wondering how it paints the pattern data at the bottom of the screen (the song “contents”). Is it double-buffered? How fast can it redraw everything? (I know from experience that plotting little 8×8 characters with the CPU can get really slow – heck, it’s even slow in the browser without optimizations!) And does ProTracker pre-render the next pattern it will display?

It’s not double-buffered; there’s only a single “sheet” of rendered pattern data in memory. It would be wasteful to do it differently, I guess, you need that precious chip RAM for samples! (On classic Amigas, all graphics and sounds must be in the same special memory region, and on an Amiga 500, it’s only 512 KB.) From address zero, the memory looks like this when a song is loaded:

For its display setup, ProTracker separates the background from the moving parts. The main screen has four colors and contains all the controls:

On top of that, there’s a single bitplane for everything else: Labels, the waveform previews, and the pattern data. This way, you only need to update dynamic data in one place (one bitplane) and not have to worry about bitplane combinations for the different colors etc.

Combined with the background and a mid-screen color change, the “dynamic” layer comes out as black, yellow, or blue:

Another mid-screen change sets the position of the “pattern sheet” (starting at row 00 above). In other words: The scrolling-up is done by altering a pointer, nothing is redrawn for that. But what is redrawn, and how fast?

When the current pattern changes during playback, all notes and effects are repainted row by row. And it’s indeed not very fast at that (each update below is 1 frame = 1/50 of a second in real time):

But there is some cleverness built in: Repainting already starts when you’re on the last row of the previous pattern. Since only the first 8 rows (00 to 07) are visible when the display switches to the new pattern, this should™ be fast enough to only show correct pattern data!

Or is it? Well, not always! If you set the song speed to maximum warp, ProTracker can’t quite keep up – captured here on real hardware:

So, what’s the take-away from this pointless excursion? When you’re going F01 or faster (like in this example, meaning a new row is played every frame), don’t trust your superhuman eyes! :)

Oh, and the Coppenheimer update will take some time. Not only because I get distracted by squirrels, erm, spontaneous side quests like this, but also because the plans are growing while I’m working at it. New ideas, keeping up with the surge of new look-into-the-box Amiga emulators (most recent), prioritizing, UI planning, yadda yadda.

Lastly, I need some distraction from not being able to be at Revision this year. Funnily enough, just in this very moment I saw this scrolling by, in BUS ERROR Collective’s latest oscilloscope-audio demo:

…which reminded me of a fast compo scribble I did last October: Don’t say it! :)