If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.
It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.
This needs a small tweak to work on macOS, where git uses the POSIX version of grep (which doesn't support `\b`). You need to use the Perl Regexp option by switching -E with -P:
I agree. Dealing with different endianness has never been an issue so long as you're aware of where the boundaries are. A call to htons() or ntohs() (or the 32bit equivalents) was the solution. I would hope all modern languages have similar helper functions/macros.
> Farting around with Amigas in 2026 means actively choosing to make things harder for the sake of making things harder. Making that choice and still outsourcing the bulk of the craft and creative process is like claiming to be a passionate hobby cook while serving professionally catered dinners and pretending they're your own concoctions.
People wanting to explore the use of generative AI for vintage computers is happening not just for graphics but for code too.
I think in the case of code though, it's still interesting because I don't believe there's been any success yet. I hear of people having success with Claude in contemporary settings but it seems to fare less well when working for older computing platforms. There's a reason for that of course and it's worth exploring.
However, it will cease to be interesting as soon as the first person manages to create something substantial. At the point, the scene should probably shun it for the reasons stated in the quote.
There's definitely been success in using generative AI for vintage Computers. Just the other day I got it to produce a bootable floppy for my Amiga 1200. It loads the network driver, uses BOOTP to get an ip address, connects to a server and then downloads code via UDP that it will then execute. I doubt you'll get it doing amazing graphical scenes like you see in the demo scene though.
What I find mind-boggling is the handwave over the rest. "Loads the network driver" - ok, which one? There's no standard network driver, only a specification for writing drivers (SANA-II). Was it a driver for SLIP/PPP over the serial port, or a PCMCIA Ethernet adaptor, or something else? Was it a copy of a driver someone's already written?
Also, it would be madness to try doing this in a bootblock, or insinuating that the bootblock did it. Demo bootblocks take over the hardware and start using their loading routines, eschewing the main AmigaOS, and that's the implication of saying something was done in the bootblock (you have under 1KB of space so the first thing you need is your own loader).
What's much more mundane and normal is a standard bootblock which returns control to AmigaDOS and lets it run the startup-sequence, whereupon you can use normal files, libraries, devices, including a full suite of other people's networking software, including BOOTP (AmiTCP comes with a client) and TFTP (see Olaf Barthel's tftpclient: https://github.com/obarthel/amiga-sana-ii-tftpclient). But it stopped being the "bootblock" that did it as soon as it started AmigaDOS.
That gives you a standard OFS bootblock that returns to AmigaDOS. Mine is a custom bootblock, same DOS\0 magic and checksum format so Kickstart accepts it, but it never enters AmigaDOS.
> What I find mind-boggling is the handwave over the rest
Fair, I should have been more specific. The network driver is the popular cnet.device which is compatible with my PCMCIA ethernet card. It's loaded from fixed floppy sectors.
> it would be madness to try doing this in a bootblock
Agreed, and I don't. It's a multi-stage boot that stays at exec level throughout, AmigaDOS is never started, no process is created, no startup-sequence runs, _DOSBase is explicitly NULL.
The disk is a standard 880K ADF with no filesystem at all, it's just raw binaries at fixed sector offsets. The only ROM libraries used are exec.library, intuition.library and graphics.library for a debug display. Everything else is self-contained on the disk.
So you're right that it isn't the bootblock doing the networking.
I used cursor with a mix of Gemini 3.1 and opus 4.6.
It referenced the Amiga ROM Kernel Reference Manual, appendix C to create a boot block in assembly. It's a raw sector-mapped image, the build process creates a blank adf, which then writes everything at it's fixed offsets and we go back with another tool to patch the bootblock with the right checksum so the kernel accepts it.
I copied that adf to the A1200 so I can then write it to a real floppy.
I no longer drink in pubs but in my neck of the woods, the pubs that specialised in cask ale often had lined glasses.
The problem was that many people insisted on the glass being filled to the brim, because they felt they were being short changed. So it solved one problem but created another.
Yes, there are a few tools that do this. Looking at /bin and the softlinks that are there, the various xz tools do it (unxz, lzcat, etc.). Also, vim. vimdiff and view are just softlinks to vim.
The only difference is that those tools have chosen easy to remember names rather than embedding the arguments as metadata in the filename.
As a generalisation of the idea though, the blog post is neat.
exiftool can embed options to executable name, not only main mode of work like grep/egrep/zgrep — it is main difference. Like running `exiftoo(-k)` is equivalent `exiftool -k`.
I've just found it and uploaded it to github. Looking at the code, I can see my horrible C style of the time. There's probably bugs galore.
https://github.com/JetSetIlly/Direwall
If I remember correctly, it runs as a commodity and patches the socket library. Interestingly, the socket library was not re-entrant (unusual for Amiga libraries) so I had to patch the Exec OpenLibrary() function to monitor the loading of new copies of the socket library. But it's been a long time so memories are hazy.
It'll be interesting to see if it is still compiles and runs for modern AmigaOS, if any active Amiga programmers are around to see.
reply