Robert Gault’s EDTASM+for native CoCo 6809/6309 assembling.

Radio Shack introduced the Color Computer in 1980. It came 4K or RAM, and Microsoft Color BASIC in the ROM. It could be expanded to 16K RAM, which allowed adding a second ROM for Extended BASIC. A plug-in disk interface cartridge came later, with it’s own ROM containing Disk BASIC.

I’ve often wondered what Microsoft used to write the CoCo BASIC ROMs in.


Around 1982, Radio Shack released the EDTASM+ ROM-Pak for the Color Computer. It was a 6809 assembler for machine language, as well as a debugger. It could load and save files (source code and final binaries) to cassette tape.

There was also Disk EDTASM+, which added some extra features — though the most important one was probably that it could load and save to a disk drive, making that process far faster.

Someone put up a nice EDTAM+ information page on my website.

Since Microsoft created EDTASM, I suspect it may have been (or was at least based on) the tool they used for writing the Color Computer ROMs.

If you want to see it in action, head over to the JS Mocha CoCo emulator where you will find it available from a menu:

The EDTASM+ ROM-Pak and Bill Barden’s Color Computer Assembly Language Programming book where how I learned 6809 assembly. I later used Disk EDTASM+.


While the CoCo 1 and 2 were basically the same machine, just with redesigned circuit boards and enclosures, the 1986 CoCo 3 was quite different. It could operate in a double speed more, and provided up to 80 columns of text versus the original CoCo’s 32 columns. It also came with 128K — double what the CoCo 1/2 could handle — and could be expanded to 512K (though third party folks figured out how to do 1 an 2 megabyte upgrades).

Unfortunately, Radio Shack never released an update to the EDTASM+ ROM-Pak or disk software. It was still limited to the small memory and screen size of the original 1980 CoCo hardware.

Folks came up with various patches. I had one that patched my Disk EDTASM+ to run in 80 columns on the CoCo 3, in double speed more (faster assembling!) while setting the disk drive step rate to 6ms. It was a much nicer experience coding with long lines!

After this I moved on to OS-9, and used the Microware assemblers (asm and rma) from OS-9 Level 1 and Level 2. I am not sure I touched EDTASM+ again until I played with it on JS Mocha, decades later.

Hitatchi 6309

Hitcachi made a clone of the 6809. This replacement chip had some undocumented features such as more registers and more op codes. EDTASM+ couldn’t help with that, but there were some OS-9 compilers that were updated to support it.

That’s when folks like Robert Gault came to our rescue with enhancements for the original EDTASM+. Robert added support for the 6309, and many new features — including CoCo 3 compatibility.

His EDTASM+ looks like this on a CoCo 3 in 80 column mode:

Robert Gault’s EDTASM+ update.

If you notice the copyright date, you’ll see he has continued to update and support it. Today he offers it in a variety of versions that run on the original CoCo 1/2, a CoCo 3, certain emulators, RGB-DOS support (for hard drive users), CoCoSDC (the modern SD card floppy replacement) as well as supporting things like DriveWire.

You can pick up your own copy for $35 as follows:

EDTASM6309 $35
Robert Gault
832 N.Renaud
Grosse Pointe Woods, MI 48236

There are a number of new features added. Here is the list provided in the README.txt file:

1) Tape is no longer supported; code has been removed.
2) Buffer size increased to over 42K bytes.
3) Directory obtainable from both Editor and ZBUG; V command.
4) Multiple FCB and FDB data per line.
5) FCS supported.
6) SET command now works properly.
7) Screen colors remain as set from Basic before starting EDTASM.
8) Symbol table printed in five names per line on Coco3.
9) On assembly with /NL option, actual errors are printed.
10) Warning error on long branch where short is possible.
11) ZBUG now defaults to numeric instead of symbolic mode.
12) RGB DOS users now have support for drive numbers higher than 3.
13) Hitachi 6309 opcodes are now supported for both assembly and disassembly
including latest discoveries.
14) HD6309 detection is included and if present incorporates a ZBUG error trap
for illegal opcodes and enables monitoring and changing the E,F,V registers
from ZBUG.
15) Coco 3 users can now safely exit to Basic and use their RESET button from
16) Keyboard now has auto repeat keys when keys are held down.
17) Lower case is now supported for commands, opcodes, options, and symbols.
Take care when loading or saving files or using symbols, ex. NAME does not
equal name, \.A not= \.a, etc.
18) Local names are now supported. Format is A@-Z@ and a@-z@ for 52 local
symbols. New sets of locals are
started after each blank line in the source code. Local
symbols do not appear in or clutter symbol table.
19) Local symbols can only be accessed from ZBUG in expanded form:
ex. A@00023  not A@.
20) Now reads source code files that don't have line numbers. Writes normal
source files with line numbers ( W filename ) or without line numbers
( W# filename ).
21) Macro parameters now function correctly from INCLUDEd files.
22) While in the Editor, the U key will backup one screen in your source file.
23) DOS.BAS can be used to program the F1 and F2 keys on a Coco3. See below.
24) Coco3 WIDTH80 now uses 28 lines of text.

Coco 1&2 versions do require 64K RAM, the Coco 3 version will work with 128K
of RAM. You can assemble 6309 code even if your Coco has a 6809 cpu.

It also adds some new commands:

V - obtains a directory from either Editor or ZBUG modes.
U - scrolls backwards through source code.
FCS - is used exactly like FCC but automatically add $80 to the last character
in the string.
FCB, FDB - for multiple entries per line entries should be seperated by a
comma. Make sure that the comment field for that line DOES NOT CONTAIN ANY
COMMAS or an error will result.
New ‘V’ directory command in Robert Gault’s EDTASM+ update.

If you are wanting to do some CoCo assembly language programming, I highly recommend you sending $35 to Robert and pick up a copy of his version. EDTASM+ is tricky to learn, and his updates make it a bit less tricky.

And tell him Allen sent ya.

Until next time…

7 thoughts on “Robert Gault’s EDTASM+for native CoCo 6809/6309 assembling.

    1. Allen Huffman Post author

      I’d been putting it off for years because I wasn’t using my CoCo, and if I did, it was under OS-9. I finally picked up a copy, maybe last year, and am just now finding time to start using it.

  1. Jim W4JBM

    The 8080 version and the 6502 version of BASIC (which was written around 1978) were both written on the PDP-10 using macros Paul Allen wrote for the MACRO-10 assembler. The source for 6502 BASIC can be found and so can the source for BASIC v 5.2 for CP/M (which still seems to be written for the MACRO-10). The GW-BASIC language from 1983 makes reference to some type of “master source” that gets “translated” to specific processors, but I haven’t found details on what they used for that. Would be interesting to see the 6809 BASIC source some day…

  2. Sebastian Tepper

    It is nice that EDTASM+ has some new additions. I used it in its cartridge incarnation a lot around 1984-85.

    One KEY feature that in my opinion is missing is a SKIP-STEP function. I explain: the regular SINGLE-STEP command (“,”) executes a single instruction, but at some point you will reach a BSR, LBSR or JSR instruction, and instead of going into the subroutine, you may want to run and stop just at the following instruction, which is the return point from the subroutine. It would be great have command that automatically inserts a temporary breakpoint at the next instruction and goes into execute mode from the branch instruction, just like many modern debuggers do.

    You can do that manually, of course, but it is really tedious and slow.

    One area where this feature is key is when you run code that points to subroutines in ROM, because trying to SINGLE-STEP into the ROM area just does not work–I suspect it is because EDTASM is trying to set a breakpoint in ROM.

    Anyway, food for thought.

    1. Allen Huffman Post author

      Sadly, G is the only ZBUG command I’ve used. I don’t think I understood what a debugger was back then. This makes me want to try it. Can you load a .BIN file in it and debug arbitrary assembled code?

      1. Sebastian Tepper

        I’m not sure if you can load a BIN file directly from ZBUG. My experience is more with the cassette side of things. I know of two ways:

        1) Assemble your code in memory using EDTASM, then invoke and go to the start address. As you have the source code, you have the benefit of knowing the labels and structure of your code.

        2) Using the cartridge version of EDTASM, you exit to BASIC, then CLOADM or LOADM a machine language program, then EXEC &HC0000 to return to EDTASM and go to the machine language starting address. In this case you are blind with respect to any labels or definitions that the code might have had. I have used this method to look into machine language games, and you can even single-step through the program and examine memory and registers as you go, but since there is no capability to step-over BSRs, it is becomes very tedious. There is this limitation regarding calls to the ROM areas.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.