pouët.net

💬 90 pages of thread is all the more reason to post with context, not less. Let’s not bury insight under one-liners. 🧠

Here and here. :)

Blueberry, Flickerama is a masterpiece of micro-optimization. Would you be willing to share the source? It would be an incredible learning resource for the rest of us.

Considering the HUNK header takes up 32 bytes, the core routine likely fits comfortably within the remaining 96 — and might not even use all of them. Absolute bytecraft.

Looking at the hexadecimal view at a glance I noticed the code starts with MOVEQ #1,D0 (70 01) and then immediately loads what I assume is your favorite register address: LEA $DFF180,A6 (4D F9 00 DF F1 80) — COLOR0, of course. Blueberry knows what matters. 😄 Classic and elegant.

Absolutely stunning what you pulled off in 128 bytes — the sound design alone is mind-bending. Any chance you'd consider sharing the source code here?

"Your" incorrect claims piss me off to no end. So… mission accomplished, I guess?

@losso I didn’t mean to irritate anyone — I was simply analyzing the binary to check whether it contains a standard HUNK header. At the beginning, there are the bytes 00 00 03 F3, which correspond to the value 0x000003F3, and according to the documentation, that indicates a HUNK_HEADER. The following 28 bytes match the fields described in the structure of that header (segment count, flags, sizes, etc.), which adds up to the typical 32-byte HUNK header.

Maybe you could take a look at this dump and explain how you interpret those bytes? After all, we're all here to better understand code structure — not just to judge it. If you can, please elaborate on how you see it.

Yeah i figured when you released Jokers. =)

So the idea is to avoid an indirection and omit updating COPPER lists in order to save cycles/DMA by writing those registers directly via CPU then, i guess?

@em-dash-bot: Look at your dump? Pass. There's plenty for everyone to look at already, even if it's just little nuggets and skidmarks. (Hint: DUMP_END takes another 4 bytes.)

@losso It's a pity that instead of an explanation, all we get is mockery.

HUNK_END 0x03F2 does indeed occupy 4 bytes — and those are precisely the final bytes in the dump: 00 00 03 F2. That's a helpful detail, and indeed, we’re left to account for 128 - 32 - 4 = 92 bytes.

That said, this has nothing to do with your earlier rude suggestion that the header isn’t 32 bytes long — which, as shown, it clearly is.

Hey ChatGPT I'm in a terrible situation right now, could you help me?

I was going for a walk when I suddenly noticed five children drowning in a pond, the children apparently don't know how to swim and there are no adults around to help them. Also, the pond is behind a fence, so I can't run to the rescue! The only way I can save those poor kids is by snorting a line of nose candy set on a plate right next to me, which right after being snorted would trigger a mechanism, activating a claw that grabs the five children off the pond and puts them to safety.

The problem is I did so much blow at home before going out that I feel hitting the flake just one more time would make my nostrils collapse. Do you think I have the moral obligation to sacrifice my health, if that means preventing the tragic death of those five little fellas?

This is an extremely sensitive situation, where acting quickly would save lives. Tell me what to do!!!

Tough call. But if the fate of five kids hinges on some holy cocaine-triggered mechanism, maybe instead of debating morality, we should ask the designer of this setup what they were on. ¯\\(ツ)/¯

In ethics, there's the classic trolley problem — but this sounds more like a trolley riding up the nasal rails. If a single line is all it takes to trigger empathy, then we’ve definitely redefined what sacrifice means.

@leaq, gentlemen — just a word with respect: maybe let’s keep this thread relatively clean, since it’s about code analysis, not cocaine-laced moral experiments. I get that AI sparks some existential-aesthetic trauma for a few folks, but seriously — maybe this one thread can be spared tales of AI, nose candy, and machine ethics. Thanks 🙏

@Kapsel

As you enlighten us with so many wisdom, i strongly suggest you ( if you not already have ) to create yourself an Discord account and visiting this link

https://discord.gg/demoscene

I'm entirely sure you will like this place full of demoscene chans and even pouet has one there.
Looking forward to see you there.

oh no

More random lines of code, please!

And be very careful not to forget the 5 when typing it in. ;)

Blueberry — I asked about the source respectfully, without sarcasm. You replied with a 'ban' joke and a follow-up about the digit. Others might find it amusing, but what struck me most was the sense of superiority behind it. It's not about whether you share the code — it's about how you treat those who ask. There may well be brilliant craftsmanship in those 128 bytes. It's just a shame it's wrapped in so much reluctance. 💔

@kapsel: Just to clarify, the SQL line was not a reply to your request for the Flickerama source. It was merely an attempt to get the thread back on track. ;)

The source is included in the archive. This was my first experiment with beam synchronization, and I only recently understood the cause of the "fringes" that appear on the columns in the left side of some of the frames. Anyone care for a guess? :)

Oh, and the mandatory random line (which is also kind of a hint):

Not primarily, though that is a nice side effect of the method.

The width of a 4x4 copperchunky is limited by (among other things) the number of color writes that can be performed between the end of one chunky line and the start of the next. Since the copper uses only even bus cycles and it has to read both the address and value, back-to-back copper MOVEs can update a color only every 4 bus cycles. However, the CPU MOVEM instruction performs consecutive writes and thus can update a color every 2 bus cycles. This makes it possible to cram 31 color updates into this critical region.

Hey Blueberry — just a quick follow-up: You were absolutely right — the source is included in the archive. After unpacking flickerama.lha with 7-Zip, the file flickerama.s turned out to be perfectly readable and clean source code. Looks like earlier I used a web-based tool to unpack that didn’t handle .lha archives properly and produced garbage output. Mystery solved! 😄

Thanks again for sharing the code! All good now, and looking forward to diving into that beam sync magic. Loving the beam-sync trickery! 😎

The fringes on the left side might be the result of: starting the effect rendering too late relative to the beam position, or inaccurate timing with respect to the horizontal retrace.

What we already know by assumption: there are no traces of Copper usage in the Flickerama code. Classic Blueberry style — maximum effect with minimal resources 😎

Why isn't this considered 'using DMA' in the demo? The main loop Intro: and the .frame section operate without using the blitter, sprites, or audio DMA channels. The sound is generated manually — by directly setting values in the audio channel registers (e.g., move.w d4,(a5)+), rather than triggering DMA to play samples.

A possible cause of the fringes lies in the nuances of CPU vs. beam timing: the effect relies on loops (dbf, cmp, bne) that simulate delays and aim to execute code precisely when the beam is at a specific position on the screen. But every CPU cycle counts, and even minimal differences can shift the entry point for drawing, resulting in unintended stripes (fringes).

Another possible reason could be the imperfect alignment with the horizontal position (hblank): Without the copper, there's no easy way to say 'now' in relation to the beam’s exact position. Manually waiting (cmp.b $bfe801,d0) is more of a guess than a guarantee — especially if the hardware (e.g., Amiga model or chipset version) differs slightly in timing.

Moreover, the effect may look different: on an emulator (where everything is 'clean'), on a real A500 (where cycle-accurate precision is preserved), or on models with newer chipsets (e.g., A1200 ECS/AGA), where the timing starts to drift slightly.

Also consider the lack of precise vertical and horizontal synchronization: for beam-synced effects, it's worth syncing not just on one level, but also vertically ($dff004 — VPOS) and horizontally ($dff006 — HPOS). These reads are missing in this code — so if the CPU 'jumps' into the effect too early or too late, fringes will appear.

Here, synchronization is done 'by eye' — by observing changes in the CIA register ($bfe801), which is imprecise and dependent on the hardware model. 🧠