The original assembler released on the CUG volume 292 (see here for the files in that volume) had support for only the Intel Hex and Motorola S19 output formats. Support for the CoCo format was added in 2006 with version 4.10 of the project:
Summary of changes/additions to the ASxxxx Assemblers from Version 4.00 to Version 4.10:
* Added support for the Tandy Color Computer Disc Basic binary file format to ASLINK.
* Other irrelevant stuff.
That's a little late (about 15 years too late) for someone buying a new CoCo and wanting support, so it's far more likely that this was a retro-computing desire. Unfortunately, there are no comments in the code or documentation that state why a change was made, just that it was made.
So we're unfortunately reduced to supposition(1), such as the possibility that the author or some other interested party got their hands on a retro CoCo at some point and wanted to use the assembler to directly create the CoCo Disk BASIC format files that could be simply dropped onto a disk and run without any issue.
The format exactly matches that specified for Disk BASIC (shown here, for example):
Offset Length Description
0 1 Value of zero indicating header.
1 2 Length in bytes of data (n).
3 2 Load address of data.
5 n Data.
Offset Length Description
0 1 Value of 0xff indicating tail.
1 2 Always zero.
3 2 Execution address.
This bears little relationship to the cassette-based format (other than the existence of blocks with specific identifiers but that's probably the case for most possible formats). The cassette format has the addresses encoded as part of the initial name-file block, before any of the data blocks begin (see here).
It's a little more similar to the scheme used in TRS-DOS for the
CMD file format as can be seen here:
A CMD File is set up with a record type header
followed by data. The record type header does
not need to be in any particular order, so the
order below isn’t necessarily dispositive:
Record Type 5 – Filename
05 nn ...
nn is length of the filename block followed
by the applicable data.
Record Type 1 – Object Code / Load Block
01 nn xx yy zz ...`
nn is 0..2, meaning that there will
be (nn + 254) data bytes.
xx/yy is the address where to put the data.
zz are the data bytes.
Record Type 2 – Transfer Address
02 nn xx yy zz ...
nn is length of the block following the
address (always zero?).
xx/yy is the address to start executing
So, in answer to your specific questions:
It seems to be specific to CoCo Disk BASIC. The source code uses
db prefixes for functions and data related to that output format and I assume that stands for
(d)isk (b)asic. I've done a fair bit of embedded stuff in my long career and never seen it elsewhere. However, that doesn't preclude the existence of use elsewhere.
Honestly, for a format that simple, the only tool you need is a scripting language like Python that's capable of working with bytes.
See the body of my answer above, maybe the author picked up a CoCo at some garage sale and just fell in love with it(2). It does have several advantages over the other two formats:
- It allows for much larger data blocks than the 256-odd bytes allowed in Intel Hex and S19. This would provide some saving, given you can reduce the overhead bytes with larger blocks.
- It gives you a file you can just write directly on to a CoCo disk and have it magically run without some external loader for the other two formats.
- Since it's binary, it doesn't bloat the data stream like the other two formats. They encode each 8-bit value as two hex characters (each of which is itself an eight-bit value, hence twice the size).
(1) As an aside, I have actually reached out to the author so will hopefully have some more "straight from the horses mouth" information sometime in the future.
And, as promised, Alec Baldwin (the author) has kindly gotten back to me with a more definitive explanation, specifically:
A long time ago I was approached by Boisy Pitre who was disassembling the NitrOS-9 operating system for the Tandy CoCo.
Boisy had previously offered some major enhancements to the conditional handling in the ASxxxx assemblers and sent me some code to add the CoCo Disk Basic as an alternate to Intel and Motorola formats.
I got the impression he was using AS6809 in the process to disassemble and reassemble the operating system code. So the code was added and thus remains a part of the assemblers.
Until recently I was unaware of his prolific publishing history.
So it appears that my suggestion, "it's far more likely that this was a retro-computing desire" may have been closer to the mark than I imagined. Especially if you look at the rather large number of retro-computing projects Boisy has been involved in.
(2) I'm sure none of us here have felt that experience :-)
load address, length, start address. (start address is needed unless you assume code starts always at the lowest address, load address is needed unless you have position-independent code, which we don't. Length is obviously needed as well). It's obvious a binary disk format has this information. You seem to be assuming some sort of "standard" required for early home computers. That wouldn't make a lot of sense - you simply cannot load a C64 prog..