DOS ain't dead

A72: PC-72 assembler, version 1.02
Released to the public domain
R. Swan

(announceded by Jim Hall on FreeDOS News)

A72 is a 8086 assembler without bells, whistles, gongs, or macros. It's a bare-bones single-segment symbolic assembler that will take standard Intel-format assembly and turn it into a COM file executable under MS-DOS.

* https://github.com/swanlizard/a72

IIRC, it has 8087 and (optional?) 186/286 support. It also includes a simple disassembler. But it lacks some things (e.g. EQU).

As a simple test, I did write a quick Sed script to get it to reassemble PSR Invaders. So it's fairly useful (and can build itself).

Related topics: TinyAsm, Evmsoft ASM, MSA2

Hello Rugxulo,

This looks like a nice project and all... but still, at this point in time, I do wish that there can at least be another assembler™ that does have bells and whistles. ????

(I mean, it is a bit of a shame that, besides Microsoft's own assemblers, the only assembler that can build Microsoft's GW-BASIC sources is JWasm, which is not GPL-compatible... Just saying.)

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I do wish that there can at least be another assembler™ that does
> have bells and whistles. ????

Best, old-time assembler with whistles is Turbo Assembler,
but we'll never see him at topic like this :(

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > I do wish that there can at least be another assembler™ that
> does
> > have bells and whistles. ????
>
> Best, old-time assembler with whistles is Turbo Assembler,
> but we'll never see him at topic like this :(

MASM and TASM are long ago obsolete. Well, MASM is still updated but hasn't been DOS-hosted since '95, and it ripped out 16-bit target since, what, 2010? Nobody cares about OMF either since forever, everything's PE/COFF or ELF or Mach-O. I sympathize with you, obviously, and there's still tons of legacy DOS code that hasn't been converted to Free/libre tools like NASM. But we're stuck trying to pick up the pieces and keeping classic things alive somehow.

If you're curious, some really in-depth history of MASM and TASM are below:

* http://bytepointer.com/masm/index.htm
* http://bytepointer.com/tasm/index.htm

A much briefer history of MASM is here:

* https://sites.google.com/site/pcdosretro/masmhist

> Nobody cares about OMF either since forever, everything's PE/COFF or
> ELF or Mach-O.

- FPC's assembler supports most instructions, including things like AVX512
- FPC has OMF writer assembler/linker
- FPC has maintained 16-bit including .COM support
- FPC is dos hosted (though not 16-bit hosted)

Is it perfect, no. But one could come quite far with it.

> it is a bit of a shame that, besides Microsoft's own assemblers,
> the only assembler that can build Microsoft's GW-BASIC sources is JWasm,

I know you need OMF support for linkable objects, which NASM has. So what exactly is holding you back? (Sorry, I haven't looked closely yet.) Preprocessor? Macros? Structs? Or just basic syntax?

NASM, since 2.15, has "%use masm" for some extra compatibility now. It's not perfect (no ASSUME overrides, no auto variable size handling), but it does help.

https://www.nasm.us/xdoc/2.15.05/html/nasmdoc6.html#section-6.5

Hello Rugxulo,

> > it is a bit of a shame that, besides Microsoft's own assemblers,
> > the only assembler that can build Microsoft's GW-BASIC sources is JWasm,

> I know you need OMF support for linkable objects, which NASM has. So what
> exactly is holding you back? (Sorry, I haven't looked closely yet.)
> Preprocessor? Macros? Structs? Or just basic syntax?

> NASM, since 2.15, has "%use masm" for some extra compatibility now. It's
> not perfect (no ASSUME overrides, no auto variable size handling), but it
> does help.

Macros, weird pseudo-ops (.RADIX, COMMENT, .XLIST, etc.), SEGMENT directives, you name it. nasm's masm.mac package --- yes, I just tried it --- is pretty minimal, and the documentation admits as much.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> > NASM, since 2.15, has "%use masm" for some extra compatibility now.
>
> Macros, weird pseudo-ops (.RADIX, COMMENT, .XLIST, etc.), SEGMENT
> directives, you name it. nasm's masm.mac package --- yes, I just tried it
> --- is pretty minimal, and the documentation admits as much.

It's built in, you don't need a separate "masm.mac" file at all, AFAIK. It does help a fair bit, but yeah, there's still many things it doesn't do (even fairly simple things). I had thought it now had support for displacements like "Blah[4]" and "Whatever[BX+2]", but rechecking yesterday implies no. So that's unfortunate, but it's not the end of the world.

Devore's NOMYSO (Perl) script (MASM/TASM to NASM) handles a few of these things (implicit sizes, weird displacements) but no "Assume" seg overrides. I did test it a bit in DOS with the old 2007 DJGPP port, and it mostly works.

I also wrote a very ugly and flawed AWK script to do most of that for me. I need to improve and rewrite it for various reasons, but it does (mostly) work. (Already done similarly in Sed, which is more limited but easier.)

It's a delicate balance, trying to be generally useful, portable, elegant, and efficient (fast without huge RAM or disk footprint or dependencies). Getting it to minimally work is only half the battle.

Jim Hall announced a week ago the new release of version 1.03. Now it has two .COMs: A72.COM (8 kb) and A72_87.COM (11 kb). See Github or iBiblio.

However, it regressed (now mishandles "OUT" somehow). So my existing Sed script for PSR Invaders doesn't work anymore ... except via workaround:

s/OUT *\([0-9]*h\)/db 0E6h,\1;&/

I haven't updated the PSR Invaders package in a year. (Well, I haven't had iBiblio access since September and still haven't gotten a new laptop. So I was only barely doing minimal mirroring via Linux USB jump drive before that.) But I did tell Jim in October that I was still working on it. However, he doesn't want to include it in FD 1.3 anyways (weird licensing??). I mentioned to the mailing list a few times (November?) that I was working on it via AWK or REXX. So I haven't worked on it since December.

But last week I did finally send Jerome a link to my files. He actually updated the package and updated his mirror on Gitlab. (I really should learn Git. They give away a free e-book, progit.pdf, on their website.)

The only obvious reason to mention any of this is because I also uploaded some interpreters (awk, sed, rexx) last month and sent a message to freedos-user ... but nobody cared. I told Jerome about that, too (smaller TC++101 build of MAWK, IA-16/GCC build of HHsed, DJGPP 2.05 build of latest Regina). You need to add -e "s/$/\r/" for HHsedGCC because it only outputs *nix LF files, which some assemblers (e.g. A72) hate.

> Jim Hall announced a week ago the new release of version 1.03. Now it has
> two .COMs: A72.COM (8 kb) and A72_87.COM (11 kb). See
> Github or
> iBiblio.
>
> However, it regressed (now mishandles "OUT" somehow). So my existing Sed
> script for PSR Invaders doesn't work anymore ... except via workaround:
>
> s/OUT *\([0-9]*h\)/db 0E6h,\1;&/
>

The problem seems to be fixed now, see Github.

---
Glory to God for all things

> > > NASM, since 2.15, has "%use masm" for some extra compatibility now.
> >
> > Macros, weird pseudo-ops (.RADIX, COMMENT, .XLIST, etc.), SEGMENT
> > directives, you name it. nasm's masm.mac package --- yes, I just tried
> it
> > --- is pretty minimal, and the documentation admits as much.
>
> It's built in, you don't need a separate "masm.mac" file at all, AFAIK. It
> does help a fair bit, but yeah, there's still many things it doesn't do
> (even fairly simple things).

I would like to write assembler to a common
subset of masm + nasm, so I am very interested
in this.

But can I do the "%use masm" without specifying
that in the assembler source file, which masm
would presumably barf on?

Thanks. Paul.

> I would like to write assembler to a common
> subset of masm + nasm, so I am very interested
> in this.

Microsoft's MASM proper is not DOS-friendly anymore and irrelevant. I wouldn't even touch it. It's not totally wrong to use older versions (even better, a more suitable clone, e.g. JWasm from last December), but I would heavily suggest NASM instead, especially after all the effort I went to for rebuilding 8086-hosted binaries.

* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/

N.B. Beware of licensing (as you're already mostly aware). MASM is still proprietary, and even "OSI" isn't "Free/libre" (e.g. JWasm or OpenWatcom's WASM). NASM 0.98.39 (NASM16) is LGPL and our untested 16-bit build of 2.09 is BSD.

> But can I do the "%use masm" without specifying
> that in the assembler source file, which masm
> would presumably barf on?

Presumably, you'd either use "-t" TASM mode to change "%ifdef" to "ifdef" to support both (as Scitech used to do) or "-P" preinclude a separate include file beforehand.

There might be some advantages to using MASM syntax, but for average or simple code, I wouldn't recommend straying beyond plain NASM syntax.

P.S. Here is an extremely informative MASM history website: https://bytepointer.com/masm/index.htm

Hello kerravon,

> > does help a fair bit, but yeah, there's still many things it doesn't do
> > (even fairly simple things).
> I would like to write assembler to a common
> subset of masm + nasm, so I am very interested
> in this.
> But can I do the "%use masm" without specifying
> that in the assembler source file, which masm
> would presumably barf on?

Specifying a "--before ..." command line option to nasm might do the trick.

I doubt though that there is such a thing as a "common subset" of masm and nasm that might be useful for writing stuff we actually want to write. I think the syntaxes and worldviews of these two assembly language varieties are quite different indeed.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

Thanks guys for your suggestions.

I personally can use tcc and tasm to compile
my programs because I bought both. I bought
bcc too.

tcc 1.01 was made freely available for download
at one point, but they then started being coy.

It's almost like all the vultures are circling
waiting for tasm to be freely available because
they know the value of it, but everyone's being
quiet about it, hoping the 8086 has been
forgotten or something. I never expected to see
westerners fighting over toilet paper, and maybe
one day I will see them fighting over the last
working XT or something.

Ideally I want a public domain assembler written
in C90 capable of running on an 8086. But I
haven't got to that point yet. My focus is still
on the OS (PDOS/86).

I don't use a lot of assembler, but I do have an
expectation that people can rebuild both PDOS/86
and PDOS/386 (loader only) real mode code with
Microsoft's tools, to build a commercial derivative.

Or tasm as a commercial replacement.

But it would be good if there was a free version
available too. I have wasm and wasmr, which work
fine, but preclude commercial use.

All of the above have versions that work on an 8086,
which is great, and I can write to a common subset,
at least of tasm + wasm which I can test.

For free, commercial use, even cross-compiling from
Windows (or Freedos+HX), I have nothing that will
accept my code. Nevermind asking for 8086 native.

I don't consider it to be my code that is wrong,
so I am reluctant to change my code.

So this new nasm option is of interest to me, as
at long last they seem to have some interest in
support the industry-standard masm (with at
least tasm and wasm as semi-clones).

Anyway, my most important code is here, part of
PDOS/386's loader:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/protinta.asm

Here is what I am getting:

C:\devel\pdos\src>nasm -v
NASM version 2.15.05 compiled on Aug 28 2020

C:\devel\pdos\src>nasm --before "%use masm" -Dmemmodel=tiny protinta.asm 2>&1 | head
protinta.asm:20: error: label or instruction expected at start of line
protinta.asm:21: warning: label alone on a line without a colon might be in error [-w+label-orphan]
protinta.asm:23: error: parser: instruction expected
protinta.asm:24: error: parser: instruction expected
protinta.asm:25: error: parser: instruction expected
protinta.asm:26: error: parser: instruction expected
protinta.asm:28: error: parser: instruction expected
protinta.asm:29: error: parser: instruction expected
protinta.asm:30: error: parser: instruction expected
protinta.asm:31: error: parser: instruction expected


Line 20 is:

% .model memodel,c


Removing the "%" doesn't help.

I'm not an assembler expert, but this is working
code which I expect to assemble by an assembler
that is 1.3 MB in size.

Adding "-t" doesn't help.

Any ideas?

BTW, I have another problem. I actually realized
that what I want to do is build PDOS/86 in huge
memory model instead of large. Watcom generates
the code I need. Turbo C++ doesn't. Smaller C
does, but uses 80386 instructions. I don't know
what Microsoft C does. Or Zortech C. Again,
ideally I would have an 8086 C compiler, but
cross-compiling from 80386 is better than
nothing. Freedos+HX is actually an excellent
environment. But I think I need to marry it up
with a laptop that can have SeaBIOS flashed.
And I need modifications to SeaBIOS too, to
get INT 14H to do bluetooth/wifi too. But that
campaign hasn't really started yet.

Thanks. Paul.

> > However, it regressed (now mishandles "OUT" somehow). So my existing Sed
> > script for PSR Invaders doesn't work anymore ... except via workaround:
> >
> > s/OUT *\([0-9]*h\)/db 0E6h,\1;&/
> >
>
> The problem seems to be fixed now

There were other changes, so my pre-existing Sed script still doesn't fully work (although I fixed it locally), but the hll/otherawk scripts work fine. Something to do with default size of INC and DEC operands (byte or word), mostly. Dunno, I'll look closer later.

> tcc 1.01 was made freely available for download
> at one point, but they then started being coy.

Turbo C 2.01 (buggy) and Turbo C++ 1.01 (better) were the freeware-ish ones, but they can't be redistributed, sadly. You can still find them on the Wayback Archive. This is why OpenWatcom is heavily preferred.

> Ideally I want a public domain assembler written
> in C90 capable of running on an 8086. But I
> haven't got to that point yet. My focus is still
> on the OS (PDOS/86).

Wolfware's WASM is (now) MIT, NASM (since 2.07) is BSD, TinyAsm is BSD. Legally speaking, although I highly sympathize, "public domain" doesn't exist in some countries. I don't remember all of the licenses of every single assembler (Octasm was public domain, maybe?). NASM (in various forms) is more or less preferred by FreeDOS.

> But it would be good if there was a free version
> available too. I have wasm and wasmr, which work
> fine, but preclude commercial use.

Actually, "open source" (OSI) explicitly means "commercial friendly". It's more or less supposed to be the same as "Free software" but with less emphasis on copyleft (e.g. GPL must always share changes).

* https://opensource.org/licenses/Watcom-1.0
* https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License

Sybase v1 is one of the weird exceptions where a license can be "OSI approved" but "FSF disapproved"! (Unfortunately, nobody was able to rectify that yet.)

> All of the above have versions that work on an 8086,
> which is great, and I can write to a common subset,
> at least of tasm + wasm which I can test.

I've been testing reassembling PSR Invaders under 8086tinyplus emulator (atop Win32) with a modified version of my old BARE_DOS (8086) floppy.

Since it's so slow and limited, I'm finding it very interesting. Luckily for me, I support so many script interpreters and assemblers. So I have plenty of options.

> So this new nasm option is of interest to me, as
> at long last they seem to have some interest in
> support the industry-standard masm (with at
> least tasm and wasm as semi-clones).

I don't think they intend compatibility at all except in very very simple cases (mostly machine-generated). MASM has waaaayyyyy too many options and features.

> Anyway, my most important code is here, part of
> PDOS/386's loader:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/protinta.asm
>
> Here is what I am getting:
>
> C:\devel\pdos\src>nasm -v
> NASM version 2.15.05 compiled on Aug 28 2020
>
> C:\devel\pdos\src>nasm --before "%use masm" -Dmemmodel=tiny protinta.asm
> 2>&1 | head
>
> Adding "-t" doesn't help.
>
> Any ideas?

Try "wasm -zcm=tasm" or "wasm -zcm=masm" or (ideally) "jwasmr".

Or just use NASM, and forget about MASM. (Sorry, but you can't really mix the two very well.)

> Wolfware's WASM is (now) MIT, NASM (since 2.07) is BSD, TinyAsm is BSD.
> Legally speaking, although I highly sympathize, "public domain" doesn't
> exist in some countries.

1. My main target is American companies (even
though I am not American), and "public domain"
is recognized there.

2. There is no harm writing "public domain"
regardless, even if it (supposedly) has no
effect in some countries.

3. There is no need to explicitly write the
word "copyright", when you're explicitly trying
to get rid of copyright.

4. Saying "you can follow CC0 if you like" (which
makes zero attempt to assert copyright, and every
attempt to get rid of it) to cover those countries
is fine.

If your intention is to write public domain code,
"some countries" shouldn't hold up the process.

If your intention is to have conditions, then
fine, that's yet another copyright/license,
but it shouldn't be blamed on "some countries".

In my opinion, obviously.

> > So this new nasm option is of interest to me, as
> > at long last they seem to have some interest in
> > support the industry-standard masm (with at
> > least tasm and wasm as semi-clones).
>
> I don't think they intend compatibility at all except in very very simple
> cases (mostly machine-generated).

I am willing to write machine-generated style.

> MASM has waaaayyyyy too many
> options and features.

I don't need that. Like I said, I'm after a
common subset.

> > Any ideas?
>
> Try "wasm -zcm=tasm" or "wasm -zcm=masm" or (ideally) "jwasmr".

It already works under wasm. My "any ideas" was
for nasm to start working.

BFN. Paul.

> It already works under wasm. My "any ideas" was
> for nasm to start working.

Have you tried Devore's (Perl) NOMYSO script? It's meant to adjust MASM/TASM sources (somewhat) to work with NASM.

I made a simple .BAT to (again) test PSR Invaders with it. It still needed a few fixes, but it did "some" things. Maybe not quite what you want, but it exists. Just FYI.

> > It already works under wasm. My "any ideas" was
> > for nasm to start working.
>
> Have you tried Devore's (Perl)

No, I haven't tried that. I was hoping to try
out nasm's MASM support out of the box.

Am I doing something unusual beyond nasm's
MASM support?

If so, is there a way of adjusting to get
what I want?

Or do I have to resort to Perl scripts because
the 1.3 MB nasm can't handle it, even with
MASM support?

Thanks. Paul.

> script[/url] still doesn't fully work (although I fixed it locally), but
> the
> hll/otherawk
> scripts work fine. Something to do with default size of INC and DEC
> operands (byte or word), mostly. Dunno, I'll look closer later.

I don't see any problem with it, if you don't specify any size in such cases some assemblers flag this as error while others assume it to be the default operation size, which for 16 bit segments is word.

---
Glory to God for all things

Hello kerravon,

> But it would be good if there was a free version
> available too. I have wasm and wasmr, which work
> fine, but preclude commercial use.
> All of the above have versions that work on an 8086,
> which is great, and I can write to a common subset,
> at least of tasm + wasm which I can test.

As Rugxulo pointed out, wasm is now (re-)released under the Sybase Open Watcom Public License. As far as I can tell, the new license does not actually prohibit commercial use.

In fact the Open Watcom toolchain is now available in source form, and it now has a nice spiffy GitHub repository: https://github.com/open-watcom/open-watcom-v2.

I think wasm --- and its JWasm fork (https://github.com/Baron-von-Riedesel/JWasm) --- are the most "open" assemblers available at the moment that can really handle masm syntax. As I said above, JWasm is one of the few assemblers that can build Microsoft's recently released GW-BASIC sources. So you probably want to give wasm/JWasm a(nother) try.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> As Rugxulo pointed out, wasm is now (re-)released under the Sybase Open
> Watcom Public License. As far as I can tell, the new license does not
> actually prohibit commercial use.

This is the problem with all these virus licenses.
You need a lawyer to interpret the 5237 conditions
and even then it comes down to some judge's decision.

From your link:

2.1 You may use, reproduce, display, perform, modify and distribute Original
Code, with or without Modifications, solely for Your internal research and
development and/or Personal Use, provided that in each instance:


I interpret "personal use" as "personal use",
but I saw someone on the Open Watcom newsgroup
try to worm his way around that.

He may or may not be right. A judge will decide,
temporarily, who is right, subject to appeals,
and even a supreme court in name-your-country
decision can be overturned at a later date.

Not interested. If it isn't public domain, I'll
use it under protest, until I've had sufficient
time to find, or write, a public domain
replacement.

BFN. Paul.

Hello kerravon,

> This is the problem with all these virus licenses.
> You need a lawyer to interpret the 5237 conditions
> and even then it comes down to some judge's decision.

True that...

> From your link:
> 2.1 You may use, reproduce, display, perform, modify and distribute
> Original
> Code, with or without Modifications, solely for Your internal research and
> development and/or Personal Use, provided that in each instance:
> I interpret "personal use" as "personal use",
> but I saw someone on the Open Watcom newsgroup
> try to worm his way around that.
> He may or may not be right. A judge will decide,
> temporarily, who is right, subject to appeals,

But there is also clause 2.2, which says you can "Deploy" the Watcom code --- which will cover commercial use --- under certain conditions.

Anyway, yes, the situation is not ideal --- that I agree with --- but it is what it is.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> But there is also clause 2.2, which says you can "Deploy" the Watcom code
> --- which will cover commercial use --- under certain conditions.

Ok, thankyou. I missed that.

I now have something for my lawyers to use if
the Watcom people sue me when I one day
commercialize PDOS/386 or a flavor of that.

Even if I'm only using their compiler, not
their runtime library.

Or even if I switch to Smaller C at a later
date, for PDOS/386 at least. Maybe they've
got long memories.

But probably at that level, Watcom is no
worse than Microsoft or anyone else with
a license. I'm still not sure if I'll be
sued by Microsoft for using Windows to
build a competitor to Windows. It's not
like I've read their 6231 license conditions
either. Or even got my legal team to
read them on my behalf.

BFN. Paul.

> I don't see any problem with it, if you don't specify any size in such
> cases some assemblers flag this as error while others assume it to be the
> default operation size, which for 16 bit segments is word.

On Saturday, Jim Hall announced on freedos-devel the bugfixed A72 1.03a (mirrored here).

1.01 never worked. 1.02 worked but 1.03 regressed (mishandled "OUT"). 1.03a changed the size assumption for "INC [BX+Var]" from byte to word. So I want the new script to work with 1.02 on up.


--- inv-a72.bat 2020-10-21 00:33:52 -0500
+++ inv-a72.new 2021-07-04 20:35:06 -0500
@@ -8,6 +8,10 @@
 ::
+::#s/OUT *\([0-9]*h\)/db 0E6h,\1;&/
 :: s/ DD / DW 0,/
-:: / DW /{
+:: / D[BW] /{
 :: h
-:: s/^\([A-Z][^ ]*\) *DW .*/s,s_\1\\[,word[,/w fix2.sed
+:: s/^\([A-Z][^ ]*\) *D\(.\) .*/s,s_\1\\[,[\2,/
+:: s/,\[B,/,byte[,/
+:: s/,\[W,/,word[,/
+:: /,[bw]...\[,/w fix2.sed
 :: g
@@ -27,2 +31,3 @@
 :: s/Word Ptr //
+:: s/\[\(.*\)[+]BX/s_\1&/
 :: s/\([A-Z][a-zA-Z][a-zA-Z][^ ]*\)\[\([1-9]\]\)/s_\1[\1+\2/
@@ -47,3 +52,3 @@
 if exist jmpshort.sed set JMPS=-f jmpshort.sed
-%SED% -f fix1.sed %INV%|%SED% -f fix2.sed -e "s/s_.*\[/[/" %JMPS% >inv-a72.asm
+%SED% -f fix1.sed %INV% | %SED% -f fix2.sed %JMPS% >inv-a72.asm


A72 1.04 was silently released on Feb. 9 on Github.

> CHANGES IN VERSION 1.04
>
> - Bug fixes I forgot to keep track of (a lot of the fixes were incidental to rewriting parts of the program)
> - Listings can now be generated, albeit without headers and page counts (trivial to add, though)
> - Segment prefixes may now be used inside of brackets (e.g. [DS:BX] and [ES:DI+BP])
> - Rewrote sections of program, fixed G6 bug (the only fix I remember off the top of my head)
> - More flexible command line parser (throw switches at it in any order)
> - Changed all messages to upper case (for a more CP/M-like feel)
> - Reformatted source program listing (for aesthetic reasons)
> - Parser now treats commas as spaces (again)

A72 1.05 was released on Oct. 9 on Github.

Changes:
* Listings are generated by default along with binary output. To have only one or the other, use the /L or /A switch, respectively (e.g. "a72 my.asm /a")
* Listings have line numbers
* Symbol tables, alphabetically sorted, are appended to listings
* More modular construction; in particular, the CPU-specific assembler module is exchangeable (6502, 8085)
* HIGH, LOW, INCBIN, ECHO, TITLE, PAGE directives added
* Lines can be 255 characters long (previously 120-something) and generate an error otherwise
* LF now recognised as valid line terminator alongside CR
* 8087 not supported after 1.04 until I have figured out how to work with floating point numerics and encoding

N.B. As of four days ago, there is also a minor update, but it has been renamed to RA. I don't know if major work is going on there or what will happen.