A18 1802 series cross-assembler

A18 1802 series cross-assembler

Last updated May 31 2023. Edited by Herb Johnson, (c) Herb Johnson, except for content written by others. Contact Herb at www.retrotechnology.com, an email address is on that page..

Introduction:

A18 is a cross-assembler for the RCA 1802, 1804, 1805, 1806 COSMAC microprocessors.My current version of A18 is at this Web link.

A18 (and other similar cross assemblers I provide) runs under Windows in a "DOS window" command line as a 32-bit MS-DOS program. It was compiled by me, from C source which I also provide. If it's compiled with a MS-DOS C compiler, the executable runs as a 16-bit MS-DOS program under MS-DOS. Ditto, Linux C compiler and Linux, OS X C compiler and OSX, and so on. I don't provide those compilations. I provide the C sources with my changes clearly marked. There are docs and sample assembly code. Bug fixes and new features are noted elsewhere on this Web page, and in the A18.DOC file. Please read the fine manual. Since I provide other cross-assemblers by the same original author, I use this Web page to describe the nature of ALL those cross assemblers. If you are using one of those cross assemblers I directed you to this Web page for all these details.

This Web page for A18, began as a 2009-2010 adaptation of a CP/M era 1802 cross-assembler called A18 to support the COSMAC 1802 "Membership Card" created by Lee Hart. Other 1802 software I have, is available from this linked Web page. This A18 cross assembler, is one of many 8-bit cross assemblers I've gathered and edited from William Colley. I provide links to them. Also on this page, are notes common to their compilation and fixes. The plain, consistent and common C code among them, is a feature not a bug which led to my support here. My contact with the original developer includes his comments, on this page. Code Developers: do not confuse stability and commonality with "not under development". This code is supported by me at my discretion. - Herb Johnson

Related information

What is assembly and an assembler? As time passes from the COSMAC ELF days of the 1970's, more people are entirely new to assembly lanaguge and microprocessors of that era. Here's some notes about how and why to use A18 or any other cross-assembler.

Another cross assembler, with macros: ASMX 2.0

To support the 1802 and the Z80, and to have a macro cross-assembler, I recompiled another cross-assembler offered freely and in C, called "asmx".Here's my slightly modified version of Bruce Tomlin's ASMX 2.0. A link to Bruce's site is on that page. ASMX will cross-assemble many vintage microprocessors codes - take a look.

A18 history and other Calley cross assemblers

A18 is one of a number of cross-assemblers, freely distributed by the developer William C Colley III, through the "C Users Group"library of C programs of the 1980's and later. A18 supports the RCA 1802, 1804, 1805 and 1806 microprocessors. The syntax is similar to other 8-bit microprocessor assemblers; it's different from RCA's original 1802 syntax.

In 2009 I (Herb Johnson) obtained a copy and adapted it to compile under the lcc-win32 Windows/MS-DOS C compiler to produce a 32-bit MS-DOS executable. I adapted A18 further, to support features of the commercial cross-complier used by Lee Hart to compile 8th, Lee's adaptation of FORTH for the 1802. Also, I contacted the author of A18, who has no objections to this use of his work; he has a few comments below.

My current version of A18 is at this Web link. The program was compiled with LCC32, a Windows 32-bit compiler. It runs under Windows in a "DOS window" at the command line. When compiled with a MS-DOS C compiler, it runs as a 16-bit MS-DOS program under MS-DOS. Ditto, other C compilers under other OS's. I provide the C sources with my changes clearly marked. There are docs and sample assembly code.

For those who download it, please advise me of any errors and issues; so I can fix them. I make zero guarantees, offer zero warrenties. I am not responsible for any loss, injury or damage to person or property of any sort. Use entirely at your own risk.

Other Calley cross-assemblers

A85, an 8080 8085 cross assembler;
AZ80, a Z80 cross assembler;
A68, a 6800 cross assembler;
A65C, a 65C02 cross assembler;
A08, an 8085 cross assembler modified for "old" 1972 8008 assembly;
A8008, an 8085 cross assembler modified for "new" 8080-like 8008 assembly;
A08_80, an 8008 1972 assembler which produces 8080 op codes;
A04, another 8085 mod, to a 4004 4040 cross assembler;

The A68 and A65x seem to be the most recent of the set, and have the "best" code. The net value of all these cross-assemblers, is the common C code and methods they share, and their simplicty and plainness. They avoid features unique to one assembler; they follow an Intel-8080-assembly like syntax; fixes to one extend to all. These are features, not bugs, not in need of "development". - Herb

More forks of A18

I essentially shruged my shoulders: I'm entirely satisfied with supporting it on my Web domain and without any terms of use; and with the permissions given me by William Colley and his prior terms. Politeness suggests some consideration of my prior and current support; but I have no means to prevent persons from adapting Calley's A18 from its public-domain release. I declined interest in Sherman's activities. So Mark says "I have contacted William Colley, and he has granted permission for his code to be released under GPL. My modifications are licensed the same." Mark's GPLed version is on GitHub. I do not support any version of A18 on github, I support the one. right. here. Issues of licence versus public domain, I leave to others.

Mark continued: "I said I would share my changes with you, but I also think you would not like to be bound by GPL. So, I am also giving you permission to incorporate any of the changes I have done on 8-27-2017 or earlier into your own version, if you would like. I have no idea if these changes are useful or interesting to you or not, but you can have them if you want them. I also want to thank you for your web page. It has a wealth of information and I've spent several hours reading information it would have taken me forever to find other places." -Mark Sherman. Mark seems to have updated his A18 for binary files support in 2017. He may or may not support the various pseudo-ops I support.

...and yet another fork of A18

Years after that 2017 "fork", someone else wanted some changes to A18, didn't get them from Mark Sherman apparently, didn't get them from me. So he created yet another github version. It would seem to have features and documents of my version. I do not support any version of A18 on github, I support the one. right. here.

Observations about all these A18's

People have modified A18, or created their own 1802 assemblers, to add new, pseudo instructions. For my support, I've chosen not to add pseudo-instructions with a very few exceptions. I support A18 to provide a simple straightforward cross assembler without unique codes and with only some features. Assemblers with additional pseudo-instructions, allow programs which support those features. But such programs are not portable, or assemble on A18 or other older assemblers. They oblige the source-code re-user to either fix the sources to replace the pseudos, or to use the assembler which supports those pseudos. The recent Elf/OS is an example of that situation.

A18 does not have "macro" capability so a user can't just add macros. This is why macro-assemblers were created. And in fact, I've supported a cross assembler for some time. Follow that link for details.

I choose not to distribute these programs on Microsoft's github; others chose to distribute their A18's there. I'm responsible for my Web domain and my A18 distributions, and I've performed these to many people's satifaction for many years. I did so before github and after. I continue to receive good comments, error reports, and questions, which I respond to as best I can.

A18 and Elf/OS

I prefer the plain features of A18, which it shares with several other Calley-produced cross assemblers; and not in use by other legacy (non-Linux) assemblers. As I maintain A18 as one of many cross-assemblers, I don't wish to add substantial changes to one and not the others. These cross-assemblers, are vintage computing artifacts themselves: stable, straightforward, and within traditional 8-bit assembly practices.

Butif you wish, you can use A18 to assemble 1802 programs for elf/OS. You'll have to bypass any "#ifdef" selection and use simple "if/elseif" features of A18. You'll have to convert elf/OS assembly pseudoops like "LOAD" into their 1802 8-bit equivalents. And, you'll have to add a list of elf/OS and BIOS call addresses. For those details, read documentation on elf/OS assemblers and programs, and inspect elf/OS assembled listings. Possibly, disasembly of assembled (compiled) elf/OS programs will be informative.

ways to compile and run A18

lcc-win32 compiler, for 32-bit command line Windows operation

In 2009 I (Herb Johnson) first obtained lcc-win32, to compile A18. Lcc-win was/is a C compiler which supports development and use under Windows at the command line or with some windowing tools. For many years, it was available on a Web site at cs.virginia.edu. As of Nov 2017 (as noted by Mark Moulding to me), it was no longer available from that University of Virginia Web site. You could use the "Internet Wayback Machine" to find an earlier version of that Web site. But in July 2018, I found a "mirror", if not an active support Web site, for lcc-win. April 15th 2016 was given as the win64 version date; win32 is not in development and is older. Apparently this site is hosted by www.iecc.com, which hosts archives of the comp.compilers ancient Usenet discussion group, among other services. If anyone has the facts about this, let me know.

But: the c code for A18 and other Calley assemblers is pretty plain, and should compile on any number of C compilers.

Running MS-DOS programs in Windows

If the above doesn't work, you can add a "command prompt" icon to your Windows desktop. Read this note.

If for some reason you operate a "16-bit MS-DOS" operating system on a computer, or Windows 95 or 98 or 3.1; you can still run a version of A18. See my MS-DOS notes above.

If terms like 16-bit and 32-bit operating systems aren't familiar, or if you've never used an MS-DOS computer before....why are you playing with 1970's 8-bit processors anyway? ;) I don't apologize for offering old but useful tools for old but interesting microprocessors. - Herb Johnson

operation of 32-bit applications in 64-bit Windows

Aug 2022: I supply A18.EXE (and other cross-assembler executables) as a "32-bit Windows command line application program". You'll have to research what "32-bit Windows" and "64-bit Windows" means, if that's not familiar to you. In this section, I'm going to explain, how to run 32-bit command-line programs on a 64-bit Windows system. Again, if this explaination is too complicated do some Web searching to find more explanations. For instance Web search "windows 7 run 32-bit command line programs". I got suggested links like this one. This and other explanations refer to "syswow64", so search on that for more information.

On a 64-bit Window system, you can apparently run a 32-bit EXE under a 32-bit version of the "command line" program (environment). That program is also called "cmd.exe" but it's in a different Windows folder. You can find that CMD.EXE in a folder called (whatever is your Windows drive and folder)\syswow64\cmd.exe Here's how to confirm that's your command-line, as a icon (shortcut) on your Windows desktop. I won't explain how to create Windows shortcuts or put them on the desktop.

If you create a "command prompt" icon on your Windows desktop, check the "properties" for that "shortcut" or icon. To do that, mouse right-click the icon and select "properties". Look in those properties for "shortcut" to see the "target" (path and program name) for that application. It will use a generic description for the Windows folder, "%windir%\syswow64\cmd.exe", that's fine, that varies among Windows systems.

If you have a 32-bit Windows, the likely "shortcut" for your command-line shortcut will be something like "%windir%\system32\cmd.exe". To my knowledge any 32-bit Windows will run the 32-bit executables I provide.

You can also run the 32-bit (or 64-bit) cmd.exe by using the Windows "run" command, and then enter the "path" for your cmd.exe. That will start the command-line window; then you can change directory over to your 32-bit cross-assembler application. But it's convenient to have a command-prompt icon (shortcut) on the desktop, to run the cross-assembler and any other Windows command-line programs.

operation in Linux

Nov 2015: Kevin Dezuzio re-compiled A18 under Linux and GCC (its C compiler) and it produced an executable program with little fuss. Kevin has notes on his compilation, on his TMSI Membership Card Web page.

Also, Mark Abene's suggested command-line script for Linux compilation is:

ln -s A18.H a18.h
gcc -I. -o a18 a18.c a18util.c a18eval.c

The Linux executable A18 program, should produce the same 1802 assembled binary code as the MS-DOS versions. Hex files will be of different size between MS-DOS and Linux due to line terminators. Contact me if you find any exceptions.

operation in Mac OS

In July 2019, Joe Blackburn wanted to run A18 under Mac OS X. It was suggested that as an MS-DOS program, it might run under a "DOS BOX" application (which runs MS-DOS programs under OS X). But Joe decided to compile the A18 C source, under his OS X High Sierra 10.13.6. A change was necessary, and there were some compiler warnings, which I'll describe shortly.

Joe said he "used the Terminal app (Mac's Command Line) using gcc. So it's essentially a Linux (Darwin) compile." Using gcc, from the terminal app, he issued the command

gcc -o a18 a18.c a18eval.c a18util.c -Wall 2>wallerrors.txt

This sends the warning/error messages to the named file (not the terminal). Alternatively he "could compile under Mac's XCODE environment, or Eclipse". The resulting A18 executable, said Joe, assembled 1802 test programs the same as A18 under a Windows environment.

One change needed was to either eliminate The "#include malloc.h" statement in the code, or create a dummy empty file of that name; the content of malloc.h appears to be unnecessary. There were numerous warnings, which could be ignored. For those interested, they are simply about using assignment statements "=" in a test-for-equality "==", as in various code-loops. It's OK to do (and was intended in this code). Often, it's not intended, it's a typo; hence the warning. - Herb

Operation in MS-DOS 16 bit

If for some reason you operate a "16-bit MS-DOS" operating system on a computer, or Windows 95 or 98 or 3.1; you can still run a version of A18. It just has to be compiled with an MS-DOS c compiler. I've used "Turbo C V2.01" from Borland to do that, from time to time, to create "A18DOS.EXE" or some similar executable file, also in my A18 distribution. It may not be of the most recent C sources, check my notes in the distribution. If there's not a 16-bit version of A18 (or other Calley's cross-assembler) in the provided ZIP file for those assemblers, ask me and I can probably add it in that way. One person reported that A68 C sources, compiled with my Turbo C, ran on their MS-DOS 3.3 8088 computer.

Bugs & fixes

"Please consider adding this pseudo-instruction ..." Probably, I won't. Look at this discussion as to why. But simply: I'm keeping A18 simple and based on vintage use of the 1802; and based on other cross-assemblers from the same programmer. That's worked out pretty well. Others disagree, and so they chose to distribute their A18's, which get confused with mine. I can't control what they do, only what I do. - Herb

"Assembly is new to me, this A18 assembler produces hundreds of errors when I try it." I addressed that in this note about how to get started with assembly language and a particular assembler. YOu'll have to read documents and figure things out. Just like in the original and now-vintage era.

Jan 2022, not fails "Value" A V error revealed that when the NOT operation is performed, it fails a later test for an 8-bit value. The test was at fault, and it's now corrected.

July 2021, .0 .1 syntax:I've added the [value].0 and [value].1 syntax to produce the low-byte or high-byte of [value]. Also: I compiled my most-recent A18 under the MS-DOS Borland C V2.01 compiler. It's in the distribution as a18_dos.exe. See MS-DOS notes in this document.

reports of "virus", program deletes when run: nope

program deletes itself: With a similar cross assembler I got this report in Aug 2015: "Your A68 program deletes itself and does nothing!" Well, that's likely an issue with your anti-virus protection. Check this note for specifics and tell your antivirus program it's OK. But if you got your cross-assembler from someone else, I won't tell you "it's OK", because it's not mine.

antivirus program gives warning: Again, I've had reports (and experienced myself) that antivirus programs see one of these cross-assemblers of mine and report a warning or "quaranteen" or delete the program. Again, Check this note for specifics and tell your antivirus program it's OK. But if you got your cross-assembler from someone else, I won't tell you "it's OK", because it's not mine.

Use of INP 0 considered harmless

Lee Hart posted in July 2020: [In the 1802, the opcode] $68 is well-behaved; it's just not very useful. It's really an INP0 instruction. The INPn instructions set the value of [the 3] N lines to the given value 0-7, and write the contents of the data bus into the memory location addressed by R(X).

N = 1-7 are easily detected by [external] hardware, so it can put "something" on the data bus to get written. But N=0 leaves the N lines in the same state they are for normal non-I/O instructions. If the data bus is floating [when the $68 is executed], then $68 will write this "float" into memory location R(X). Not useful! But, if your hardware happens to have pullup resistors, or some input device that puts something on the floating data bus [at that time], then $68 becomes an 8th INP instruction, and can be useful. - Lee Hart

A18 assembles INP 0 correctly, but flags it as an error. A18 also assembles OUT 0 correctly and flags it as well. - Herb Johnson

RCA M record out; DS

March 2019: I added an alternative to Intel hex records, namely RCA "M-records". To specify this output, on the A18 command line use "-M filename.hex" not "-I filename.hex" as in Intel records. The output file is a series of "M addr bb bb bb .. bb;" records. The Intel type 1 address-only record is provided as an ";M addr". In theory, old RCA type ROM monitors will accept this M-record format to load the data at the addresses given. In practice, you may have to hand-edit this file.

In June 2019, I added the "DS" pseudoop as an alternative to "BLK". Both allocate space but not values. Hex and M records won't be produced. In the binary files, 00's filled the space for this assembler; in July 2020 I changed the fill to FF's.

backslash escape codes

June 4 2018: Loren Christensen provided code to interpret C-language '\something' embedds in strings. Read the A18.DOC document for the full list of supported escape characters. I tried to add '\0' but that's a string null-terminator, it cuts off strings. You can work around that.

Binary file out

May 27 2017, binary file: Mark Sherman suggested to me, to add a binary-file output to A18. So I did. The "-b" option on the command line, lets you name a file to receive the binary result of assembly.Please let me know the results of your testing. Please read the A18.DOC file for descriptions of how binary files work. Also read the paragraph below.

Consider these limitations. 1) The binary file starts where the assembly code starts. Whether you ORG it to 0000H or F000H, the binary file first-value is the first value assembled. 2) If your asm code uses more ORGs or PAGE or other means of changing the address of assembly, the binary fill will "fill" (at that time with 00H, in 2020 with FFH) to cover gaps. Why is obvious, if you think about it. Hex files don't fill - think about why they don't NEED to. 3) If you ORG your program to a LOWER address than the current assembled address, A18 will stop with an error. It can't fill the binary file "backwards". OK?

June 28 2020: The fill character for binary out, is now FFH. That's what is expected in erased or unused EPROMs. A few 1802 developers have called this out to me, when their code expected to test for unused ROM memory.

SCRT, interrupts

Another Web page discusses 1802 code which supports the RCA COSMAC Standard Call and Return or SCRT routines. Those provide subroutine "call" and "return" features which are common to other 8-bit microprocessors. RCA's document also supports 1802 interrupt instructions and a sample interrupt service routine or handler. Those were implemented in the earliest of RCA's ROM monitors - see RCA's COSMAC manual MPM-201. These routines were also part of a monitor program called RCABUG which was developed decades ago by Tom Crawford. See that Web page for details and relevant 1802 code.

In March 2018, thanks to Loren Christensen, I added pseudo-ops CALL and RETN; he did the coding but A18 made it simple. CALL addr generates "SEP R4, DW addr" where addr is the address of the called routine. "RETN" generates "SEP R5", and is the return from a subroutine. The A18 distribution includes source which represents software support for CALL and RETN, without use of those pseudo-ops. Refer to the SCRT Web page mentioned for more discussion.

However, in Sept 2021 it was called to my attention, that the RCA 1805's hardware instructions for CALL and RETURN (SCAL, SRET) have a different stack-order between high and low bytes, than the pseudo-op CALL and RETN that RCA recommended for the 1802. I added notes accordingly to the SCRT Web page linked above. So be aware of this difference if using A18 with the 1805 processor.

other fixes by date

Jun 2020: FILL options As noted above, the binary fill-in value is now FFH not 00. I added a @nnn numeric prefix to support octal numbers (of course use 0-7 digits only). I added a pseudo op "FILL vv, count". This fills memory from the current location for "count" bytes, with the "vv" byte value. Maximum count happens to be 255 decimal, and the value must be a byte-value 0-255 decimal. I'm pretty sure all the 1802 04 05 06 mnemonics are spelled correctly and are the RCA preferred values; I also assemble the RCA alternatives. INP 0 and OUT 0 are assembled but flagged as errors, it's convenient to do both.

See if my most current hex-to-bin tool, fills in with 00H or FFH.

Mar 2018: A18 correctly handles short-branch instructions which "straddle" memory-page boundaries. With the 1802 series, the memory page (XX00h-XXFFh)of the branch address byte, not the branch op-code, is the correct memory page for the executed branch-address. If I were you, I'd avoid coding like that. ;)

Later in Mar 2018 I added Loren's CALL and RETN support of subroutines (as they support RCA SCRT standards). Also, his suggestion, the "-l file" (lower case L) command produces a low-case listing file, and "-L file" (capital letter L) to produce an UPPER CASE listing file. (shrug)

Aug 2015: "Your A18 program deletes itself and does nothing!" or My anti-virus program flags your program as a virus!" Well, that's likely an issue with your anti-virus protection against "unusual" programs. Check this note for specifics.

Aug 30 2010: I made small changes to the source, to compile under Borland's MS-DOS based Turbo C. Both a Win32 executable and the MS-DOS executable are included in the Zipped package. The MS-DOS version may not be current. - Herb Johnson

The assembler produces the following when there's blanks or no values between or before commas:

001 000 002 000 DB 1, ,2,,

I could not fix that. If you fix the source, let me know - Herb Johnson

Related cross assemblers, operating systems, compiling

I provide a whole set of cross assemblers like A18, all from the same programmer and with similar code. These comments on those programs, on operating systems and compiling, probably apply to all of those ancient programs, and this Web page is where I collect these comments. - Herb

Other binary and hex tools

It's convenient to have tools to convert between "binary" files and "Intel hex format" files. There were many such tools provided in the MS-DOS days and CP/M days. Look at archives for those programs, usually called hexbin, binhex, etc. . But my friend and colleague Bill Beech, wrote his own "bin2hex" program in C, among other software tools. I adapted his code and rewrote a "hex2bin" version too. Here's a ZIP file of hexbin in C and for MS-DOS.Likewise, here's a ZIP file of bin2hex in C and for MS-DOS. Don't like MS-DOS? Recompile and let me know.

See if my most current hex-to-bin tool, fills gaps with 00H or FFH.

RCA's 1802 ROM monitors and assemblers, just loaded and produced code in a simple hex-dump format. The format is an address, followed by hex data bytes, ending in a semicolon. The first record begins with a "!M", which tells the RCA monitor to start loading. So: here's a C program and MS-DOS exe, to convert RCA hex dump format to Intel hex format files. And here's the converse, a C program and MS-DOS exe, to convert Intel hex format files to RCA hex dump format

Sometimes all that's available for an assembly-source file, is the assembler listing. That includes line numbers and opcodes on the left. Here's some dirt-simple utilities to remove N columns. One of them skips lines with a ";" semicolon in column 1. That's a kind of odd case. Anyway the C code is there, if you want to deal with some other odd case.

Comments from William C. Colley III

Will Colley wrote A18 and other assemblers under BDS C in the early 1980's. A18 and A68 (for the 6800) became CUG disk #149 of the "C User's Group CUG diskette library for 1985. He later updated them for other compilers, and became the "librarian" for those CUG disks and others which have his assemblers. I managed to find the author today, 25 years later. Here's what he had to say about his work, in mid-Feb 2010, quoted with his permission. - Herb

I haven't updated those assemblers in many a year. In the late 1980's, Microchip Technology lead the charge of putting tools into the hands of people designing with their parts. See MPLAB. All other microcontroller vendors have followed suit. Thus, I no longer needed to build assemblers myself.

Since you seem to be intested in old history, settle back an I'll tell you a story.

Back in 1977, a college friend and I built computers together. His was a MITS Altair 8800 and mine was an Imsai 8080. We were poor undergraduates, so we didn't start with the luxury of disk drives. Instead, we used a cross-assembler running on a Datacraft 6024 mainframe to build a ROM operating system for our machines. I did the file system (Tarbell cassette interface), debugger, command interpreter, and EPROM programmer (2708 and both 2716's). He did the assembler, the line editor, and the screen driver routines (Imsai VDO board). The object images came over to my system on punched paper tape. I had one of those readers where you shined your desk lamp on the thing and pulled the tape through by hand.

A week or so before we left for graduate school, we got the systems to the point where they could regenerate themselves. We loaded the source code from cassette tape a piece at a time into RAM, assembled the piece, then loaded more. We had to rewind the tape for the second assembler pass. Still, it worked. We were roomates at MIT where we continued debugging the thing until we had it working quite well.

Later in 1978, we finally each amassed the sum of money (about $1500 -- a lot to a poor grad student of the time) required to put in a pair of 8" floppy drives each and went over to CP/M.

In my work at Draper Laboratory, I needed to do development for the MC6800 microprocessor. That's when I wrote the first of that long line of cross-assemblers. The original was under BDS C, though I quickly ported it to Aztec C II as it became available. At the time, commercial asemblers of similar capability cost $450, which I though of as highway robbery.

The 1802 assembler was to support a consulting job I did while in Boston. The 8048 assembler was to support a design I did at the company I worked for after graduate school. I came out here in 1983 and my needs changed further resulting in the assemblers for the Microchip processors and the 8051. The 8085 assembler was done as an instructional tool to help some of my colleagues out here with their college courses. The others (6502, Z-80, etc.) were done on request.

Well, now you know.

You may do with the assemblers what you will. They are froth far back in my wake at this point. The thing I didn't want to have happen was for someone to build a high-cost commercial package around my code. Instead, I wanted other folks to be able to get the kind of yeoman service out of them that I did. The folks on the GNU project did a far better job on the licensing that I ever could have conceived of. If I had done those assemblers a few years later, they would have been released under the GPL.

We've come a long, long way since the late 70's to early 80's.

- Will Colley

C User's Group

The "C Users Group" status seems to be "not active" as of well before 2018. The "C User's Group" appears to have been operated by a person who once offered a CUG library plus his own updates (above number 430 or so), in a 1999 book and CD-ROM. Also, the content of the "C User's Journal" which supported CUG, appears to have been acquired by the group which owns "Dr. Dobbs", another previous journal. However, drdobbs.com Web content was "frozen" as of Dec 2014 (but available as of July 2018). Some content from a number of CUJ issues, CUG files plus CUJ sources, were published on a "Dr. Dobbs" DVD, possibly in 1999. Walnut Creek, a CD-ROM distributor, produced a C User's Group CD-ROM in 1994 and in 1999.

But diligent searching on the Web as of 2016, for "C users group" or "CUG CD-ROM", will likely find previously-released CD-ROM images or files of portions of the CUG library. They will likely be releases from 001 to 400 or 500 so, up to about 1998-99. A few sites, only list directories of the CUG library.- Herb

This page and edited content is copyright Herb Johnson (c) 2023. Copyright of other contents beyond brief quotes, is held by authors of that content. Contact Herb at www.retrotechnology.com, an email address is available on that page..