Posts Projects //TODO /posts/2023-09-06_building-dave$_

Building Dave

AGT (Atari Game Tools) is a set of tools and libraries built by DML, aka Douglas Little, and to be frank the guy's knowledge of Atari ST/STE/Falcon development is humbling. AGT makes it quite easy to get started moving sprites and backgrounds around the screen in ways that would have dropped jaws back in the day, because Douglas has done the hardwork for you. What it doesn't do is bring down game development to entry level. It's a bit of a moving goal post and can be a little confusing, but that doesn't detract from it's magnificence. Years ago I started work on a platformer using it, but having not touched it for far longer than I meant to, I really want to get it going again. Of course, AGT has changed in the meantime and now I've got some work to do to get it building once more, let alone running.

This is a sort of real-time rambling journal of my efforts in doing so.

Setting Up AGT

The first step is to clone the AGT repo from bitbucket.

Next comes building the various graphics tools AGT provides (these are used for sprite & background cutting and conversion to formats used by AGT). This is a relatively simple job if you're in a *nix environment (macOS, GNU/Linux, WSL, or MinGW all work). Some Windows binaries are provided but on other platforms you need to go through the various directories in the tools directory, and run make in each.

As a test I tried compiling one of the examples and failed almost immediately: on this OS (unlike most of my other systems) I don't yet have a 68k GCC cross compiler installed. There's a few options out there, the most well known arguably being Vincent Rivière's m68k-atari-mint cross-tools, but there's reasonably old now and I know GGN has a thing for brown [1] and has a repository with a shell script called bigbrownbuild that can generate GCC cross compilers for a veritable pile of GCC versions. The last time I tried to get this to work I failed, though I can't recall what computer or platform I was trying it on.

Before writing the last paragraph I couldn't remember the name of the repo, so I simply searched for "atari gcc brown" and inevitably ended up on the correct site, GGN's blog titled "Beyond Brown". From there I found the relevant link but first I totally got distracted reading about The twist and I can't say it was time mispent. No least because I tripped over the following quote in there, which seems rather apt for my current scenario:

Putting tasks off for long periods, especially for reusable code, is sure to make them look daunting or impossible as time passes.

Good point. Dave's not re-usable (yet) but putting it aside for so long has left me completely out of tune with that code, and with AGT.

Here we go.

Run the script, fail fast. Check the log file indicated by the command run (build-binutils-13.2.0/binutils_build.log)

Install makeinfo with apt-get install texinfo. Praise ye gods for teh gigabits.

Run script again

Wait. Wait more. It might be building ok?

matt@pop-os:~/Develop/Atari/bigbrownbuild-git(master)$ ./
Host machine: Linux
Cleaning up build dirs from previous build
Downloading all relevant archives
Unpacking binutils, gcc, Newlib
Building gcc 13.2.0...

Configuring, building and installing binutils
Building the actual cross binutils...
Configuring, builing and installing gcc (without libs)
Building the actual cross gcc...

Nope, failed on the next step, building mintlib:

Source patching and building mintlib

Oops, something exploded while building!
The error happened while buildgcc was executing make SHELL=/bin/bash &> mintlib_build.log

You may inspect the following logfiles for further info:
binutils_config.log, binutils_build.log, binutils_install.log
gcc_configure.log, gcc_build.log, gcc_install.log, gcc_libc_build.log, gcc_libc_install.log
mintlib_build.log, mintlib_install.log
gcc_libstdc++_build.log, gcc_libstdc++_install.log
gcc_misc_build.log, gcc_install_build.log
gcc_type_traits.log, gcc_type_traits.log
binary_strip.log, binary_strip.log

Errors list a lot of log files, but the key is in the command output. We want mintlib_build.log for this one, which for me is at mintlib-bigbrownbuild-13.2.0/mintlib_build.log. The error in this case was a missing pre-requisite because I was too lazy to determine if they were installed or not after reading about them in Such is the life of a coder: often it's all too easy to make assumptions and waste time slowly proving them incorrect. In this case it was bison, easily fixed with a sudo apt-get install bison since I'm on an Ubuntu based distro[2][3].

Run the script again, get further. I'm still waiting but the last line logged to stdout is "Building and installing the rest" which is promising, though I am wondering what "the rest" entails.

A few minutes after that and I see this:

~/Develop/Atari/bigbrownbuild-git/build-gcc-13.2.0 ~/Develop/Atari/bigbrownbuild-git/build-gcc-13.2.0
Reorganising MiNTlib folders
Building and installing brownout
Creating an archive with all the goodies
All done!

Guess we're all done then. The first thing to do now is check that the binary is there and runs, then see if there's an example program to compile with it (seem to recall reading there is as of some particular version), and then get back to configuring AGT to use it.

I'd configured the script (you literally edit some things in the script file itself, read the readme!) to build into ~/Develop/Atari/brown and sure enough there's now a few directories and files in there. bin, naturally, is where I want to look and the first smoke test is good:

matt@pop-os:~/Develop/Atari/brown/bin$ ./m68k-atariturbobrowner-elf-gcc --version
m68k-atariturbobrowner-elf-gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

Going back to the repo, there's a directory called barebones and that has a few sample source files along with a .bat file to build them. I'm not going to nerd snipe myself now and convert that, so let's just try compiling the cpptest.c. file, which seems like a pretty good candidate for testing C++ compilation. Assumung (yet another one) GCC norms I try an optimistic m68k-atariturbobrowner-elf-cpp ./cpptest.cpp expecting maybe an a.out or a.tos or similar. Instead I see a few screenfulls of C++ source and nothing to suggest compilation is taking place. Sure enough, running ls right after shows no new files. Guess it's time to read build.bat after all. the readme. Always read the readme. I figured checking the readme again before diving in would make sense, and whaddayaknow, there's a section titled 'Building the "barebones" examples'. It tells you to run make. Somehow, until now, I've completely failed to notice the Makefile sitting right there in front of me. Let's try make:

matt@pop-os:~/Develop/Atari/bigbrownbuild-git/barebones(master)$ make
m68k-atarimegabrown-elf-gcc -c -m68000 -Ofast -fomit-frame-pointer -fstrict-aliasing -fcaller-saves -flto -ffunction-sections -fdata-sections -fleading-underscore -D__ATARI__ -D__M68000__ -DELF_CONFIG_STACK=16384 -Wall -o vsnprint.o vsnprint.c
make: m68k-atarimegabrown-elf-gcc: No such file or directory
make: *** [Makefile:234: vsnprint.o] Error 127

Ah. Of course. Wrong shade of brown. Updating the Makefile to use turbo rather than mega power might do it... nope: turbo isn't just turbo brown, it's turbo brownER. Yes, I said this would be a realtime ramble, and if this makes no sense, well the executable was once m68k-atarimegabrown-elf-gcc and now it's m68k-atariturbobrowner-gcc. While fixing this I also noticed a library path that needs to be updated because ggn isn't a user on my machine [4]. Also brownout.exe is clearly for Windows, removing that extension should be fine because brownout was an executable built alongside the various GCC cross compilers.

brownout: brownout.cpp:418: std::map >::iterator get_section_for_va(elfsectionboundsmap_t&, uint32_t): Assertion `_va >= reference_bound->second.first' failed.
make: *** [Makefile:190: lolworld.elf] Aborted (core dumped)
make: *** Deleting file 'lolworld.elf'
rm lolworld.o

Ok. There's something quite funny about this failing on lolworld, but I'm tired, my bourbon is finished and I'm going to try and get my head around this assertion another time. Hopefully tomorrow because I seem to be on a roll.


Part II

  1. I'm honestly not sure if it's the word or the colour that takes his fancy. I must ask about that. ↩︎

  2. Pop_OS! for those interested ↩︎

  3. Side note: remember when package installs involved lots of slow downloads? These days the install often takes longer than the data transfer: Fetched 962 kB in 0s (2,874 kB/s) ↩︎

  4. As far as I know anyway ↩︎