AmiBlitz 3.13.0b brings smarter memory management to classic Amiga coding

There are software updates that arrive with fireworks, banners and a feature list so loud it almost needs its own power supply. AmiBlitz 3.13.0b is not one of those. This is a quieter kind of release, but not a minor one. It is the sort of update that sits closer to the workbench than the shop window: practical, technical and aimed at people who actually spend time building things on Amiga systems. For developers still writing for 68k Amiga machines, the small details matter. Memory is not some endless background luxury. It is a resource you feel. It is the difference between a program behaving neatly and a program slowly turning into a grumpy houseguest. That is why this release deserves attention. AmiBlitz 3.13.0b focuses on memory handling, library clean-up, IDE behaviour and documentation. Not glamorous, maybe, but very useful. In the Amiga world, useful has always had a certain charm.

Memory takes centre stage

The most important change in AmiBlitz 3.13.0b is the arrival of a proprietary memory pooling mechanism in memlib. That may sound like something only a compiler engineer could love, but it tackles a very real problem: memory fragmentation.

On classic Amiga systems, especially older configurations, memory can become fragmented when programs repeatedly allocate and free blocks of memory. The machine may still technically have free memory available, but that free memory can be scattered in pieces too small or awkwardly placed to be useful. It is a bit like opening a drawer full of cables and discovering that every single one is tangled around a mouse from 1997.

The new pooling mechanism is designed to reduce that problem. Instead of leaving every allocation to become part of a larger memory traffic jam, memlib can now manage memory in a more organised way. The result should be cleaner behaviour for programs that create, use and discard data while running.

This is especially important because the feature is aimed at executable programs on Amiga OS versions below V39. In plain terms, older Amiga environments are not being left behind. That matters. Retro development is not only about running old software on overpowered modern setups. It is also about respecting the machines and operating systems that made the platform what it is.

A release built for real machines

One of the more appealing parts of this update is that it feels grounded in the realities of actual Amiga use. Many classic machines are expanded, upgraded, accelerated or emulated in different ways, but there is still a strong interest in software that behaves properly on more modest systems. AmiBlitz 3.13.0b speaks to that audience.

The focus on memory pooling for pre-Kickstart 3.0 systems is a good example. It shows that the project is not simply chasing the easiest target. Older Amiga setups can be unforgiving. They do not politely hide bad behaviour behind gigabytes of spare memory. If your code is wasteful, the machine will let you know, sometimes with the emotional subtlety of a brick through a window.

By improving memory handling at the library level, AmiBlitz gives developers a better foundation. This does not mean every program will suddenly feel transformed overnight. It does mean that certain kinds of software, especially those using dynamic data structures, can benefit from more predictable memory behaviour.

That is the sort of improvement users may not notice immediately, but developers will value. And in development tools, that is often where the best progress happens.

Memlib becomes more than a helper

With this release, memlib grows in importance. The new pooling system is not just an isolated trick hidden inside one part of the environment. AmiBlitz 3.13.0b also adds internal function calls so that other Blitzlibs can use the new pooling mechanism.

That is a smart move. It turns memlib into a stronger shared base for memory-related work across the library system. Instead of each part of the environment handling things in its own way, the new functions allow more consistent memory management.

For programmers, that matters because consistency reduces surprises. And surprises in programming are rarely the fun kind. Nobody compiles a project hoping for a mystery. The only mystery most developers want is why there is still coffee in the pot.

This broader use of memlib also suggests that the update is looking beyond one quick fix. It gives the wider AmiBlitz environment a better structure for future improvements. That is good engineering: not noisy, not flashy, but solid.

Linked lists get a cleaner foundation

The linkedlistlib update is one of the most meaningful supporting changes in 3.13.0b. Dynamic lists now use memlib for memory allocation and deallocation. That fits naturally with the new memory pooling work, because linked lists are exactly the sort of structure that can create a lot of allocation activity.

A linked list is built from individual nodes. Those nodes can be created, connected, removed and destroyed while a program is running. In a simple program, that may not be a big deal. In a larger tool, game, editor or utility, those small operations can pile up. On a classic Amiga system, they can also contribute to memory fragmentation if they are not managed carefully.

By moving linked list memory handling through memlib, AmiBlitz makes this part of the system tidier and more consistent. The improvement is unlikely to produce a dramatic “wow” moment on screen. There is no spinning 3D logo to announce better allocation behaviour. But for developers who rely on dynamic lists, it is a welcome piece of plumbing.

And as every long-time computer user knows, plumbing only becomes exciting when it breaks.

Arrayslib gets a sensible clean-up

AmiBlitz 3.13.0b also moves linked list initialisation routines out of arrayslib and into linkedlistlib. This is one of those changes that sounds small until you think about what it means for long-term maintenance.

Libraries should be organised logically. Array-related routines belong in the array library. Linked list routines belong in the linked list library. That sounds obvious, but mature programming environments often carry older decisions forward for years. Over time, code can end up living in slightly odd places because it once made sense, or because nobody had the time to move it.

This update takes the tidy route. By putting linked list initialisation where it belongs, AmiBlitz becomes easier to understand and easier to maintain. Developers digging through the libraries will have a clearer map of where things live.

It is not the most glamorous kind of improvement, but it is the kind that keeps old projects healthy. Software ecosystems age better when someone occasionally opens the cupboards, throws out the mystery adapters and labels the boxes.

The IDE gets a small but welcome comfort feature

The AmiBlitz IDE also receives a useful addition with the new VIRTUALSPACE tooltype. When enabled, it changes how the cursor behaves during vertical movement. The cursor automatically moves to the end of a line when moving up or down.

That may sound like a tiny editor preference, but editor behaviour is personal. Developers spend a huge amount of time moving around source code. A cursor that behaves in a more comfortable way can make everyday editing feel smoother.

This is the kind of feature that will matter most to people who live inside the AmiBlitz editor rather than simply launching it once every six months. It is not a revolution, but it is thoughtful. It shows attention to workflow, not just compilation.

Programming tools are full of small habits. The way a cursor moves. The way a line is selected. The way a window remembers its settings. These things do not make headlines on their own, but they shape how pleasant a tool feels over time. VIRTUALSPACE is one of those small touches that can quietly reduce irritation.

And reducing irritation is a perfectly noble goal. Possibly the noblest goal in all of software development.

A stubborn library bug gets removed

The update also fixes an ALibJsr unknown token bug in iffmakelib. The issue was caused by Blitzlib number reordering, which is exactly the kind of sentence that can make a casual user slowly back away from the keyboard.

For developers affected by it, though, this fix matters. Library ordering problems can be deeply frustrating. They often do not look obvious from the outside. The code may appear correct, the library may appear available, and still the compiler throws up an error that feels like it came from behind a curtain.

Fixing this bug makes the environment more predictable. That is important in any programming system, but especially in a classic development setup where users may already be juggling different OS versions, library sets and hardware configurations.

A good compiler should not make developers feel like they are negotiating with a goblin under the desk. This fix removes one more point of friction.

Documentation gets some needed attention

Documentation has also been improved in this release, with updates covering areas such as UsedMem, Dim and other parts of the system. That fits neatly with the broader theme of AmiBlitz 3.13.0b. When an update focuses so heavily on memory handling, commands and explanations connected to memory and declarations need to be clear.

Good documentation is easy to underestimate. Everyone wants new features, but when something goes wrong, suddenly the manual becomes the most important file on the machine. In retro development, documentation is even more valuable because users are often working across different generations of hardware, emulators and operating system versions.

Clearer documentation helps new users get started and helps experienced users confirm details without relying on old notes, forum posts or memory. And developer memory, as many of us know, is not always reliable. Ask any programmer why they wrote a clever routine six months ago and enjoy the silence.

Better documentation also supports the long-term health of AmiBlitz. A tool is easier to keep alive when its behaviour is properly explained. That is true for new users, old users and anyone returning to Amiga development after a long break.

Why this update matters

AmiBlitz 3.13.0b is not trying to reinvent the language. That is a good thing. Mature tools do not always need reinvention. Sometimes they need better foundations, fewer rough edges and cleaner internals.

This release does exactly that. It strengthens memory handling, improves dynamic list support, reorganises library responsibilities, fixes a specific compiler-library issue, adds a useful IDE option and refreshes documentation. Each change may look modest on its own, but together they make the environment feel better maintained.

That is important because AmiBlitz occupies a special place in the Amiga software world. It is not just a nostalgia object. It is a tool people still use to make things. Games, utilities, demos and experiments all benefit from a development environment that continues to receive practical updates.

The Amiga scene has always been held together by people who care about details. Sometimes those details are visual, sometimes musical, sometimes technical. In this case, they are mostly technical, but no less important.

A practical update with long-term value

The best way to describe AmiBlitz 3.13.0b is as a workshop update. The bench has been cleared. The tools have been sorted. A few loose screws have been tightened. The lighting is better. Nobody has installed a disco ball, and frankly that is probably for the best.

For developers, the headline is memory pooling. For daily users of the IDE, VIRTUALSPACE may be the small quality-of-life improvement they notice first. For library maintainers and experienced programmers, the clean-up around linkedlistlib and arrayslib will be appreciated. For anyone who has hit the iffmakelib issue, the bug fix will be more than enough reason to update.

It is the kind of release that rewards people who read beyond the version number. There is no single dramatic feature screaming for attention, but there is a consistent purpose behind the changes. AmiBlitz 3.13.0b makes the system more stable, more organised and more comfortable to use.

In the world of classic Amiga development, that is not boring. That is exactly the point.

A sharper AmiBlitz for 68k development

AmiBlitz 3.13.0b shows that meaningful progress in retro computing does not always have to look modern. Sometimes progress means making old systems behave better. Sometimes it means respecting limitations instead of pretending they do not exist. Sometimes it means spending time on memory allocation, library structure and documentation while everyone else is distracted by shinier things.

This release is aimed at the people who still enjoy building software close to the machine. It gives them a stronger base, especially on older OS versions, and it improves parts of the development experience that matter over time.

That makes AmiBlitz 3.13.0b a worthwhile update. Not because it changes the identity of AmiBlitz, but because it strengthens it. It keeps the tool practical, focused and useful for the community it serves. And really, for a classic Amiga development environment in 2026, that is a pretty good trick.