For a lot of “demo coders” tools to write directly to floppy disks were as necessary as assemblers to build the demos. I created my own because I needed the tools and didn’t have access to or even know any pre-existing tools to do the job. The disk writing toolkit I ended up with was “PutBoot” to write a “boot sector” to a floppy disk (because that needs a checksum calculation), and “TDWrite2” (a re-write of an earlier tool) to write everything else.
PutBoot was an interesting challenge. It was a very early tool and a lot of my code was using bits and pieces written based on (with hindsight not great) advice from an Abacus book on programming the Amiga in assembly language.
However the first challenge was I didn’t actually have an actual source code file.
I had at some point decided to use a source code control system call RCS (Revision Control System), so what I had was an RCS file called “putboot.s,v”
A quick browse within Amiga lead me to “rcs_56.lha” within “dev/misc”. Whilst there is part of me that thinks I should actually use this again for these projects for the time being I’ll let you be happy that I’ve done the work to download and install RCS, lookup the bare essentials required to “check out” code, and reclaim my source code file. Linux users probably have “GNU RCS” in their distro which can pull the source code from the RCS versioning file.
I had a blob of code called “std.s” and an include “std.i” (std short for standard) and for my early assembly language programming used it everywhere. This was full of macros the assembler I tried at one point HATED. Having discovered this during the library re-build I was ready.
The code pulled my “std” file using an Amiga assign that I created called “asrc”. Because I had mostly moved my programming sources from drive to drive to drive in the past, in my rescued PutBoot source code folder had a script to make this assign to build the tool…
Assign asrc: Zaphod:AvA500/Main/OldHD/prg/68k/src
Let’s “unpack” this… it was originally on an “old hard drive” (OldHD) that was later moved to a partition on a new drive “Main”, and later when I had an A1200 with four partitions on the hard drive remnants of my A500 (Aardvark’s A500) was on a partition called Zaphod. IIRC that was the third partition, after Workbench and Work. I think the fourth partition was called HDGames or maybe just Games. As can be inferred from this, once a file existed that was its “forever home” in my brain, and moving from one hard drive to another the story was always the same, put the entire old drive (or at least pieces of it) on the new one and just continue to use the old files.
So after “checking out” the source using RCS all that was required was locate my “standard” code blob, fix the macros, and fiddle with include file paths in the PutBoot source.
TDWrite2 was, as can be guessed, a second version of a tool to write files to disk using “trackdisk.device”. This second version was clearly written after a 2.04 upgrade to my A500 as I had written it to use a 2.0+ dos.library feature ReadArgs to parse the command line. The original used the “std” code blob, and there was one version for code and one for data. The new version was written to write anything.
I couldn’t build it. This time through no fault of my own, and digging deeper the fault lies with Commodore.
It turns out that from the 2.0 NDK onwards the Commodore developers didn’t actually “flesh out” all the assembly language include files with all the new features, and an important file called dos_lib.i that should contain a list of all the dos.library functions stops short, not carrying any of the V36 or later system calls, including ReadArgs and FreeArgs. I never noticed before because I’d previously used a commercial assembler and they had free-reign to adjust or re-build certain files.
The gitlab resource “complete-ndk39” has been mentioned in the past and that contains a version of “dos_lib.i” that includes these references. I copied the “dos/dos_lib.i” file and put that into my include tree, i.e. Work:prg/include/dos/dos_lib.i so that my “standard format” of Makefile that I’ve been creating can pick it up in favour of the original file without “losing” the original. Later I took the OS 3.2 NDK version of dos_lib.i and added the V36 and later calls to that.
The only other thing was this tool was coded to use another “shared” blob of code “wbinit.s” as program initialisation code, which is worth talking about by itself. Locate, copy, done.
To accompany this article there are four LhA archives. These are not required if using the “quick” scripts from a prior blog post.
Continuing on from having setting up some custom includes and the “aardvark.library”, to continue constructing the “toolkit” copy the LhA files into the “AmigaDev_XFER” hard drive area of FS-UAE along with the “dos_lib.i” file referenced above (just loose in the folder) and get everything installed using AmigaShell as follows:
Cd Work:prg MakeDir include/dos Copy xfer:dos_lib.i include/dos Lha x xfer:std.lha Lha x xfer:PutBoot.lha Lha x xfer:wbcompat.lha Lha x xfer:TDWrite.lha Cd PutBoot Make Make install cd /TDWrite Make Make install
The makefiles in the PutBoot and TDWrite archives are again configured to use the AmigaOS 3.2 NDK, so after extracting the LhA files people using the “NDK39” files would need to adjust the ASFLAGS line as before. People using the “quick scripts” these files are already extracted and the Makefiles in those versions are configured to use an “assign” to find the NDK files. See also the “aardvark.libary” blog post for details.
If there are no errors you will end up with two new command line tools to write to floppy disks… Well… ADF files as we’re in an emulated environment, but the emulated Amiga doesn’t know that… We have tools, but I think maybe a little background on AmigaDOS and Workbench from an assembly language viewpoint might be interesting…