Another demoparty, another demo ...
I made NAPHTA!
Released at RSYNC 2025.
An OldSkool demo for Amiga OCS inspired by a live performance I attended and captured of NAFT, a Belgian Live Analog Techno band.
The music is partially based on,
or at least HEAVILY inspired by "Paroxysm" by Naft.
If you want to check out the MOD file -> here in Bassoontracker.
It
runs on an Amiga 500 with 512k fast ram or beyond.
Technically, it's a big step up compared to my previous
production, but still: baby steps.
I really wanted to use assembler, but progress was just too slow.
I
got to the point where I could load some graphics and put them on a custom screen in assembler.
Yay! almost a
demo! But then each additional step took another week of dabbling and tinkering.
Deadline Rsync was approaching, so I made the executive
decision to move back to C.
Hardware banging this time.
I found this YouTube series "Amiga hardware
programming in C" that I could wrap my head around, and it gave me some much-needed direction.
Thanks Wei-ju
Wu!
Another "aha moment" came when Gigabates explained what the copper actually does, and - in essence -
how simple it is.
He said "For graphics, you can think of the copper as timed palette changes: You just wait for
a certain position on the screen, and then you can set any color index to any color, and then it will use that color
from that position going forward"
"Ping! ..."
Ooh!!! I can do something with that!
I started some experiments to have a patterned image
on screen. the image stays static but when you start switching colors, you can target each pattern section
individually and give it a unique color, circumventing the usual 32 color limit.
This is of course a well known
"copper chunky" trick, but I found it interesting that each "pixel" doesn't have to be square, it can be anything
you want.
This formed the basis of most of the effects in Naphta. (can you call them effects?)
I aimed
for some sort of stained-glass visual.
To keep things simple, I used horizontal patterns in 16 or 8 colors, so I
could avoid swapping colors midway on a scanline.
Also, I stayed away from color 0 to avoid having to reset it
each line when entering the overscan areas.
Yeah.... not the most hires copper-chunky, but it was a nice
experiment and usefully to wrap my head around the copper.
This is the image for the soft pixel blur
anims. The picture doesn't move, the animation is just the copper, setting palette colors like crazy.
The
"slowness" is not the copper, by the way, it's the C code that has to calculate the correct copperlist index of each
position. I probably should/could precalculate that too.
I'm still largely clueless in C-land. I really should dive into BartMans toolchain and set up a proper
monitor/compiler.
But even now:
Boy, oh Boy, oh Boy, now I FINALLY understand why everybody loves those
custom Amiga chips.
What a beautiful system.
Another interesting bit - Or at least I though so -
was the use of the music to drive the timing of the effects, and not the other way around.
I'm using the
excellent PTPlayer replay library and this supports
reading out the "E8" command.
This way you can let the music
control which part of the code should be triggered, and you still can use all the Fxx commands you like to set the
music speed.
Double handy in my case as I don't have a clue how fast my code runs (I know it's sloooow though
:-) ) and often routines take several frames to complete, so having an external thingie to keep the timing is
nice.
And a third concept was that I got somewhat obsessed with "transparency" on Amiga.
Fact is:
transparency doesn't exist on Amiga OCS but ... we have bitplanes!
Bitplanes are layers stacked on top of each
other, and you can use that to "fake transparency" if you reduce the color count.
For example this scene uses 5
bitplanes, 32 colors.
The first 3 bitplanes are the base image in
8 colors.
Then the spotlights are on bitplane 4, forming colors 9 to
16.
So if you set those colors to a slight variation of the first 8 colors, you get
the impression of a transparent layer.
And we still have 1 bitplane left, so we can repeat this trick on
bitplane 5, forming the colors 17 to 32, giving the impression of 2 transparent layers.
The
way the display works on the Amiga is that each bitplane is "just a chunk of memory".
You can just point to
other memory sections if you want to display something else so you don't have to copy things around.
This means
that scrolling a bitplane is just "setting the pointer to the address of the row below".
This is trivial if you
know it, but it took me quite some time to switch my mental model of a "a screen is something you draw to" to "a
screen is just a display of several memory blocks".
Once you make that switch, suddenly you realise you can do
some pretty cool tricks.
Combined with the careful palette mapping, you then get - for example - the appearance
of a semi-transparent layer that is moving on a background.
Some key takeaways for future productions:
In general: I feel I'm just scratching the surface, still so much to discover and to learn, and making small
productions like this is an excellent way to do so, so ... on to the next one!
Source code is on
https://github.com/steffest/naphta/
Some more background info:
Tools Used:
Graphics:
Based on
live footage from the band "NAFT"
Images where first sketched on paper and then produced in PhotoShop, including
the Generative Fill tool, so I guess they are not AI free.
So yeah: those nice smoke effects are generated, not
pixelled by hand.
Images were finalized and pixel optimised in Dpaint.js.
Some chunky-pixel animations were taken from Giphy.
Music:
The main theme and some samples where lifted from the song "Paroxysm" by Naft using
various stem-splitting tools.
The mod file was composed by hand using BassoonTracker:
The disk version of naphta uses a
lower-quality compressed mod file to make it fit on a single disk and in 512k chip ram.
Code:
Home-cooked hardware banging C.
Compiled with SAS-C on the Amiga (but written in
modern editors)
I picked up one of my old projects again: BassoonTracker!
BassoonTracker is some sort of music sequencer in the "tracker" tradition.
Very retro, very geeky - I love it :-)
Most people - including me - use it more to listen to other peoples' songs than to create their own, so I polished the "playing experience" a bit and added playlists, amongst others.
Above is a small video of the new stuff on version 0.5.
Check out the full changelist of this release at the history page.
Underneath the surface, the code also got a mayor and long overdue overhaul: I moved to ES modules, making the code much easier to maintain and much easier to expand.
As a result, the initial footprint is much smaller - coming in at 97kb compressed - which is quite nice for an app that
For the past months, tracked music is more or less on non-stop repeat when I'm working as - for me - it's the perfect coding music. (After all; it's code itself !)
I like the fact that tracked songs are by nature open source: playback is in real time generated from the source samples, the musical notes and the effects.
If you hear an interesting part, you can instantly investigate how it was done.
Because tracked music comes from a time where diskspace was limited, the files are usually very small and don't contain long samples or lyrics, making them even more perfect as coding backgroiund.
I must say it makes me surprisingly happy that the BassoonTracker source code repository jumped the 1000-star marker recently.
Yay! I'm glad people still like tracked music.
(Check out this playlist with "demoscene releases" of this year - it really is a vibrant scene ! )
The BassoonTracker app can be found here - source code is here.
![]() |
![]() |
![]() |
The trend of enhancing retrocomputers with new hardware expansions is still going strong.
Nowadays we can "implement" hardware designs in software and use FPGAs and raspberry PIs to replace and improve old and aging components.
The newest star is the PiStorm32: a bridge between the expansion port of the Amiga 1200 and a raspberry PI.
This means you can use the modern features and speed of a raspberry PI to "emulate" all sorts of Amiga hardware.
The piStorm32 supports the rasberry PI 3A, 3B and 4. PiStorm is an open source project by Claude Schwarz.
I got mine from Cédric who was kind enough to produce a first batch of the PiStorm32-lite
(note: the "lite" in the name doesn't mean there's a "full" version somewhere, it means the original hardware design was updated to work around the world-wide component shortage)
Note that there are 2 main ways you can use the PI in the piStorm:
One way is to run linux on it, and configure your Amiga emulation from the linux side. This feels a bit ... yuck and is a few bridges too far for me: when you switch on the Amiga, you have to wait untl the Linux side has booted for it to provide emulation services. The benefit is that you can use this linux bridge also for things like networking etc, but I feel: if you want to go that route, why not just install a dedicated emulation package like Pimiga or AmyBerry on the PI and be done with it.
The other way - much more exciting - is Emu68 - this is a bare metal 68k emulator for ARM devices. Ok, it still has to boot, but as it's bare metal, it boots in milliseconds and it's WAY faster to emulate the 68k CPU.
Emu68 is a project of Michal Schulz.
I already got a PI3A+ running in a Amiga 500 and 2000, so I mostly was interested in the potential speed increase of using a PI4. Boy ... Is was not disappointed!
This ... thing ... flies!
Ok Ok, I know the Sysinfo benchmarks mean doodly squat whern JIT emulation is enabled but still: it does show the shear horsepower: 2333 MIPS / 2235226 dhrystones ... I've never ever ever seen such numbers.
And it's noticeable: everything seems zippy zippy fast.
It also seems the slow CHIP ram access mostly has been solved.
The fast ram is configurable and by default set to 2GB. 2GB Ram in an Amiga .... that's insane.
I really like that you can access all the settings and configuration of the PI from inside the Amiga.
From the Amiga side you also get all the tools to monitor the PI.
By default the PI4 runs at 1.5GHz but there's a setting to make that 2.2Ghz. (That's how I got those 2333 MIPS)
The PI runs at 70°C then - compared to 50°C cliocked at 1.5GHz. Still well within limits.
The configuration files are stored on a FAT32 partition on the SD card that you can access from the Amiga side.
This also means you can use this partition to quickly share files between the Amiga and your PC/Mac. Super handy.
One of the nice things of the piStorm, is that it acts as any other accelerator card: you can still use all the native Amiga hardware.
For example, you can still boot from your internal IDE interface, or floppy disk even. It then just provides the ROM, RAM and CPU.
If you really want to go "stock" again, you can completely disable the piStorm by holding down the reset keys while booting. Nice.
But you don't put in a piStorm in your 1200 if you want stock, of course ... you want SPEED!
Did I already mention it's fast?
MPEG and AVI video plays smoothly, decoding mp3 is hardly noticeable (in contrast to a main task that drains even a 060 CPU).
Obviously the software that gains the most of the CPU and RAM boost is the software that plays nice with the system and avoids direct hardware banging. Emulating other systems for example: these run mostly on the CPU and require some ram.
Here's the Classic MacOS 8 being emulated on the Amiga, running PhotoShop 4.
Faster then it ever was, including on the original mac hardware.
Is it all good?
No.
As with all "super accelerator cards", compatibility with hardware banging software like games and demos is not super great.
WHDLoad goes a long way of ironing out the kinks, but still I experienced frequent crashes running some games and demos.
So if you're main interest is playing classic Amiga games or watching demos, the piStorm is not your best friend.
But then again: with the kind of performance the PI delivers, it might even make more sense to run these things in an "emulated Amiga" on top the real Amiga. perfectly doable and about the only way to ensure the "hardware" is exactly era-correct and what the software expects.
Another annoying part is the cable clutter the PI introduces, especially if you want to extend the SD cards to be accessible from outside the case.
Of course, this is no different then with other cards for the Amiga 1200, but the PI can be more extreme if you want to access the regular PI ports like USB and Ethernet too. I guess it will be another round of extension cables and 3D-printing to make it all fit nicely.
About 3D printing: the PI3 has plenty of space, but the PI4 pushes a bit against the trapdoor it 's closed.
I guess designing and printing a trapdoor that gives a bit more space and ventilation for the PI is a good idea.
Likewise, the PI GPIO pins are VERY close to the metal of the Amiga keyboard. For that reason it's really recommended to put some extra insulation between the metal keyboard plate and the PI.
Verdict:
I love it.
It's clear that this is THE future of Amiga accelerator cards.
Yes, it still has it's flaws, but things are progressing rapidly and everything is open source.
What a big contrast with those other fast Amiga Accelerator cards ...
I must say one of the first thoughts in my head when testing the piStorm was "Ouch ... this means game over for Apollo"
with the PIStorm delivering 4 times the performance at a quarter of the price of those other cards, it pretty hard to justify getting an IceDrake or a TF1260 ...
What I like:
What could be better:
Excellent excellent work by Cédric, Claude, Michal and many others.
If you like the project, please consider becoming a Patreon of Michal and/or voicing your support on the PiStorm Discord channel
Aan de ene kant heb je de tirannieke dictator.
Op papier leidt hij een democratie, maar hij weet wel beter.
Hij is een narcist die niet maalt over "de waarheid", die de media manipuleert en uit is om zelf aan de macht te blijven.
Of misschien vooral nog om zijn persoonlijke rijkdom uit te bouwen.
Hij overtuigt zijn land om - met hulp van de bondgenoten - andere landen binnen te vallen als hij denkt dat dat winst gaat opleveren, uiteraard allemaal met een goed verhaal.
Er is immers een bepaalde "dreiging" die moet worden afgewend.
De waarden en normen zijn in gevaar en moeten worden verdedigd.
Niet altijd is dat binnenvallen fysiek: de belofte van financiële en militaire steun werkt soms evengoed.
---
Aan de andere kant heb je de populist. Hij opereert in een democratie, maar hij speelt het spel beter dan wie ook.
Hij is een narcist die niet maalt over "de waarheid", die de media manipuleert en uit is om zelf aan de macht te blijven.
Of misschien vooral nog om zijn persoonlijke rijkdom uit te bouwen.
Hij overtuigt zijn land om - met hulp van de bondgenoten - andere landen binnen te vallen als hij denkt dat dat winst gaat opleveren, uiteraard allemaal met een goed verhaal.
Er is immers een bepaalde "dreiging" die moet worden afgewend.
De waarden en normen zijn in gevaar en moeten worden verdedigd.
Niet altijd is dat binnenvallen fysiek: de belofte van financiële en militaire steun werkt soms evengoed.
---
En ertussen zit het plebs. Niet denigrerend bedoeld want ook ik hoor erbij.
Het plebs kiest partij, roept hoe slecht die andere wel niet is en trekt ten strijde.
Digitaal uiteraard, op social media met vlaggetjes en slogans, met steunbetuigingen aan de goeden, met aanvallen op de slechten.
Ze worden aangespoord en vooruit gestuwd, gevoed door welgemikte beelden, video’s, verhalen en grapjes.
Maar pas op voor die verhalen van de andere kant, want die zijn niet echt, dat is propaganda en niet te vertrouwen.
En de nuance, de rede, de menselijkheid? Sorry, daar is geen plaats voor.
Je bent voor of tegen, wit of zwart.
Ik voel mij precies niet meer thuis in deze wereld.
Waar zit toch die poort naar dat parallelle universum, waar misschien wèl iedereen naar het midden vloeit, in plaats van naar de buitenkant.
Waar onvermijdelijke verschillen en conflicten worden bekeken als interessante nieuwe invalshoeken in plaats van als dreiging.
Waar misschien elke man of vrouw juist dat is: mens tussen andere mensen.
Ondertussen zet ik beter "het nieuws" af, en focus mij op mijn kleine wereld waar ik wel invloed op heb. Op de mensen die ik graag zie, en zij mij.
Ik weet dat het een bubbel is, maar het is een bubbel waar ik mij gelukkig wel thuis voel.
I did a new "paint job" on an Amiga case. (Normally they are white)
I am totally in love :-)
The case is one from a1200.net in "CD32 grey".
I also pre-ordered the matching keycaps like 2 lifetimes ago - but they still have to deliver, always a lurking issue with these kickstarters.
Anyway - I decided to do a DIY.
I posted it on some forums and got surprisingly many reactions asking how I did the keycaps.
Super easy actually, but here it goes.
I used iDye Poly. It's a dye that bonds with most plastics but - luckily - it doesn't bond with the little protective cover that is on the letter of the keycaps on Amiga 1200 models.
This result in the original key-color shining through as a small border around the lettering, making sure the letter is still readable.
Rather a funky effect!
Before dying, make sure you're keys are super clean and evenly coloured. I even brighted mine a bit with hydrogen peroxide.
The instructions that come with iDye Poly are meant for dying fabrics. They tell you to use boiling water, but whatever you do: DO NOT BOIL YOUR KEYCAPS!
They will warp and bend, making them unusable. (believe me, I know from experience :-/ )
I used water of about 50 °C.
Add the dye, add the color intensifier that comes with the dye.
Stir, pop in keys.
I use a 1 liter transparent plastic bottle with a wide opening. That way you can close it and give it a good shake, making sure all keys are subdued in the dye.
I used the "silver gray" color for the gray keys. The dye works pretty fast and I only left them in for about 2 minutes.
The black keys I left soaking for a few hours (in the color "black") and that was a mistake.
After some time, the dye builds up to a sticky goo, making the keys a bit smudgy.
I evened them out with some acetone rubbing but still they are not a sharp as they should be.
I finished them of with a few layers of matte varnish for the gray keys and high-gloss for the blacks.
I knew upfront this would make them dust-magnets but hey ... looking as cool as that is hard work!
then the finishing touch: I designed a custom badge with the vampire logo in CD32 theme and asked the "BadgeMan" to print it.
Cherry on the pie!
I did one before - a 600 model.
There I did the complete case and painted the keys black.
I applied some Amiga-specific keyboard stickers made by iComp.
Also nice!
Presenting a new (small) project.
It's an insanely simple Catalog System to keep track of your collections.
People who know me know I'm a bit of a collector.
Ok, some call it "hoarder" but I call it collector.
The difference between a collector and a hoarder is that the former knows what he has and keeps everything in good shape.
Still ... my retro computer collection is growing towards a point where I don't know exactly what I have anymore, or - more frequently - where I put it.
Questions like "I know I have this Amiga accelerator card, but ... where the heck is it?" need answers.
There's a ton of software already out there to help with that but I wanted something super-super-simple and with some very specific features.
As experience taught me: If it's too hard to maintain, it won't be.
When you start googling or asking around you get responses like. "Oh, an SQL database is what you need" or "There's an app for that, I use Collectorz or Numento"
No, no, no, nonono - been there done that. This is not my first attempt at cataloguing.
All other attempts stranded in
Did I mention it should be simple?
So: no database, no third party software, no fancy stuff.
Plain files and folders, plain JPG and .TXT files.
You structure your collection in folders. Each folder can contain files and subfolders that further describe your item. Info is stored in plain text files. Images are stored in .jpg or .png. Any other file you add is just regarded as "file".
Then, a script is run that pulls all these files into data-structure.
This .json file is used to display a webinterface with browse and search features.
When you edit/add content from the webinterface, the local files are changed.
The "database" is always being generated from the local files. This means your data is your data: it lives in your folder as plain text files, completely outside Kiss-catalog.
If you stop using Kiss-catalog and delete it from your system, your hard cataloguing-work is not lost.
The main info file is called "info.txt"
The main image of an item is called "main.jpg"
If you want to display your collection on the web, simply put all your static files on a webhost.
No database or serverside processing needed.
Everything runs
There's a small demo collection at http://www.stef.be/collector/amiga/ (read only)
Still starting to populate it, first I have to FIND all stuff :-)
And of course: Open Source and everything.
It's made for personal use, but you're free to give it a go. Feature requests are welcome.
It runs one Node but if that doesn't ring any bells there are also pre-compiled binaries for Windows, Mac and Linux
These "design" decisions have some drawbacks:
I've been pondering the last few months (years?) over something I call "sustainable software"
It's probably not a new concept but that's what I call it in my head.
Basically it means that a developer should write software that is as simple as possible for the job.
Not because simplicity is a goal in itself, but because simple software lasts longer.
It's easier to maintain, consumes less resources, runs faster, ...
Developers should write software to last.
It's all too easy to quickly throw something together using the funky libraries and frameworks that today are considered "modern". Before you know it you're lugging along a staggering dependency tree and rely on a multitude of online services to get your thing built/compiled/deployed.
Yes, you're the cool kid on the block, but how will it look in a few years? Will it still build/compile/deploy?
If it's a fairly simple web-app, do you really need that 2 MB javascript package, 7000 lines of CSS and 4MB initial page load? Maybe ...
In this project "sustainable software" means:
Anyway - that's food for maybe another blog post - don't get me started on frontend builds that pull in ONE MILLION packages and takes 20 minutes and 8gig to build ...
For now: Happy Cataloguing!