A nice slogan for a t-shirt! Bit long, maybe…

Not so long is the list of new pointers I’ve added to the Amiga Pointer Archive. It’s just these four guys:

One of them is a blog reader submission, taken from a 1992 utility disk (thanks, LocalH!), and another one was a sketch by myself to test the social media sharing feature of the minisite. The other two appeared after the big update – I did a fresh scan of pouët links and went foraging at some FTP sites. And fixed some bugs while I was at it!

In the end, about a thousand new disk images showed up, but after filtering, nearly all the pointers on them were already in the database. That’s disappointing (in numbers), but also cool: I wasn’t missing a ton of pointers as I feared. I did try my best, though:

• RAR files weren’t processed at all (many pouët prod links have them)
• Neither were LHA archives
• Buried in the code was a val limit = 100000 from debugging, and the number of ADF files was of course just above that
• Upper-case file extensions like were ignored

Most of all I’m glad I resisted the temptation of passing arbitrary condiments, i. e. clean up the code and do a “proper” rewrite. The pointer-file collecting process has become a convoluted mix of self-written programs, external tools, and manual steps.

Painful, but with a rewrite and a cool new über-tool I would still be in the stage of building an ivory tower of code without anything to show for it.

One thing I might add in the future is a method to submit hand-drawn pointers directly to the archive – people are drawing not nearly enough Amiga mouse cursors nowadays! :)

Go visit the archive, see if you can spot the four new additions, and have fun exploring! Maybe even start pixelling a new pointer and save a handy URL for later, using the “export” button…

Months ago, I spotted a cool camera at the local Ramsch-, erm, “antique store”. Last week, I finally gave in and bought it – a nice little Game Boy Camera!

I’m still impressed with the picture quality coming out of the 128×128 pixel sensor.

Naturally, two new questions emerged:

• What is the best way to transfer the photos off the device in 2026, and why is it so complicated?
• What is the legislation on posting old photos you find on a camera you bought if the resolution is only 0.014 megapixels?

The last question might be a non-issue. Everything around the Game Boy Camera is about fun and playfulness. It’s packed with mini-games and whimsical features – which the previous owners wisely used to protect their anonymity… :)

I was staying at a… mature hotel this week. Look at those comfy stairs! Don’t you want to take a nap on them right there and now?

As a bonus, the room had a TV that was not built into the wall or otherwise obstructed. The HDMI port was accessible, and I could connect my mini PC to the TV. All of a sudden, a magic moment emerged:

Together with the retro furniture, and feeling clever for bringing the cable, and seeing my stuff appear on the hotel’s TV screen that was showing a soap opera moments before – I felt like I was eight again: We were visiting grandma and granddad; my brother and I had brought our exciting new Commodore Plus/4 so we could hook it up to the black-and-white TV in the tiny playroom upstairs. The feeling of accomplishment we had after all the fiddling to get it to display the computer’s picture – our picture, the one that we controlled! Back then it was figuring out how to adjust the channel frequencies on the TV, scanning through endless static until the BASIC prompt began to form; now, it was finding a picture mode that doesn’t chop off the borders and doesn’t apply a horrible sharpening filter.

Sadly, the image above cannot fully capture that emotion. Was it because “hijacking” the TV programme felt similar? Or because the mini PC doesn’t have its own display and needs the TV, just like the old Plus/4 did? That it only needs to work at all, and the resolution or colors don’t matter?

Or maybe the smell is just missing. :)

The time has come. Time for cat content on my website, that is – just to share the joy and a little surprise.

On with the cat content and the surprise; here’s the neighbor’s cat playing with their new toy like it’s the best thing ever since scratching the leather sofa:

Now, the cat playing with it so frantically isn’t the surprise – that thing is probably loaded with catnip. But after the cat was “done”, i. e. exhausted from the drug-induced frenzy, I looked at the toy and had a wait-a-minute moment.

You be the judge! I’ll say: Cosmic coincidences for the win – it’s my Valentine’s Day picture that ran on Finland’s Teletext service!

You’re seeing it too, right?

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! :)