Aztec C 3.2b on one 800K disk

I had the ProDOS release of Aztec C65 3.2b sitting around as eight 140K disk images. Swapping eight floppies to compile a file is nobody’s idea of fun, and I have a 3.5" drive on the IIe, so I wanted the whole thing on one 800K disk.

What I tried

AppleCommander’s acx did the merging. Created an 800K ProDOS image named /AZTEC, made CC, LN and UTIL directories, and copied the tools across from each disk. Every .LIB went into LN/ so the linker’s CLIB variable finds them in one place. The shell’s PROFILE assumed four separate volumes (/system, /cc, /ln, /util), so I rewrote it:

set PATH=:/ram:/aztec:/aztec/cc:/aztec/ln:/aztec/util
set INCLUDE=/aztec/cc/include
set CLIB=/aztec/ln/

Two acx surprises. create -f to copy boot blocks off the SYSTEM disk died with a null pointer, I think because there’s no BASIC.SYSTEM on it. And write -b refused to write blocks 0 and 1 to the 800K image at all. Ended up reading the two boot blocks out of the SYSTEM disk and dd-ing them into the first 1024 bytes of the .po file.

The eight disks hold more than 800K, so the .ARC library source archives and the DOS 3.3 target libs went on a second image. You don’t need either to compile.

It booted first try. Then I typed cc exmpl.c and got this:

The Manx shell unloads itself to run a program and reloads SHELL.SYSTEM afterward. The reload is a little native stub the shell parks at $BD51, and it builds the pathname from a directory string the shell stashed at $BC11 plus the literal SHELL.SYSTEM. That stub loops forever on failure, so a reboot is the only way out. Typing set showed the problem:

The shell computes its home as the ProDOS prefix plus whatever is sitting at $0280, the spot where the launcher leaves the name of the system file it just loaded. Manx assumed a bare filename there, which is what a 1986 Disk II boot gave them. On this machine $0280 had the full path, so the shell glued /AZTEC/ onto /AZTEC/SHELL.SYSTEM, and the double slash is an invalid ProDOS pathname. Setting HOME in PROFILE doesn’t help; the stub gets its copy during init, before PROFILE runs.

The fix is a loader that boots first. AZTEC.SYSTEM is 186 bytes of 6502: copy itself to $0300, SET_PREFIX to /AZTEC/, OPEN and READ SHELL.SYSTEM into $2000, write a bare SHELL.SYSTEM string to $0280, jump. ProDOS boots the first *.SYSTEM file in directory order, so I deleted SHELL.SYSTEM and re-added it after the loader.

cc calls as on its own, so there’s no separate assemble step. cc -A stops after codegen and leaves the .asm for reading.

What I measured

• Eight disks total 1,116,160 bytes used. An 800K volume has 819,200.
• AZTEC.po: 1411 blocks used, 188 free, about 94K for source and objects.
• Loader: 186 bytes.
• Hello world with printf: code 11,274 bytes, data 552, uninitialised 68, total 11,898.
• Linking that one object against c.lib (59K) off the floppy is slow enough to notice.

What broke or surprised me

• The shell’s builtins are lowercase only. SET with caps lock on goes looking for a file called SET, fails, and drops into the same reload loop.
• The 3.2a in every signon banner is fine. The READ.ME says 3.2a was the last beta and 3.2b is the same binaries with the beta label removed.
• VED is arrow-key driven. hjkl does nothing.
• 11.9K for hello world. Aztec links whole library modules, and printf drags in stdio, buffered files, the ProDOS I/O layer, the console driver and malloc. Every C call goes through helper routines and a software stack because the 6502 has nothing that looks like a C frame.

Next

Nothing on the C side. This was a one-off to see what the experience was like, and the answer is that Merlin is a better place to write for this machine. The disk stays useful for grep, diff, hd and a working 800K ProDOS boot. The loader trick applies to any old system program that expects a bare name at $0280.