CODOS (Channel Oriented Disk Operating System) is the name of the Disk Operating System made by MTU for KIM-1, SYM-1 and AIM-65.
It required the K-1013 floppy disk controller, 8 inch disk drive(s) and optional the K-1008 Visible Memory.

CODOS V2 was the version for the MT-130/140. Numerous software was available, see the MT-130 page for manuals.
Dave Plummer (of Dave’s Garage) has a KIM-1 system with various MTU cards, including the K-1013.

CODOS Disk images

CODOS Manuals

CODOS Manual
CODOS User Manual
CODOS User Manual OCR’ed
QumeTrak 842 Maintenance Manual

Dave Williams has the following, not yet dumped by him, disks:

  • MACASM 1.0
  • MAGIC/L Language
  • MTU-C
  • MTU-FORTH79 2.1
  • WOPDPIC 1.0 NEC 8023 Printer Version
  • MTU-130 User Group Diskette #3
  • MTU-140 User Group Diskette #5

Me and my KIM-1

My first computer is a KIM-1. Still have it! A life changing experience!

This is the story of me and the KIM-1.

Philips educational kits.

As a young child, at age 12, I was introduced to electronics with the Philips electronic kits. First a Pionier crystal radio. Easy to build, good instruction manual. Lots of listening pleasure!.

Two years later I bought the Philips EE8 Electronic Engineer kit. Again nice builds (the 8 stands for 8 experiments), with a good manual. Since the manual covered the expansion to the EE20 for 20 experiments, I bought the parts myself one by one at Aurora Vijzelgracht, Amsterdam.
More on the Philips kits on my website dedicated to electronic kits.

Radio Bulletin

In 1978 I bought my first computer, a KIM-1. It turned out to be a Rockwell rebadged Rev F Mos Technology board.

The beginning of lots of fun, learning, member of the KIM gg Club and making and publishing in the dutch electronics magazine Radio Bulletin and the KIM Kenner.

In 2014 the big KIM-1 machine was finally taken down in parts, the following photos showed the end result as in 1985 after many years of tinkering.

The KIM-1 system ended as a real production system until 1985, mainly to write articles, all Radio Bulletin and KIM Club Magazine related work was done with this system.

My KIM-1 workplace in 1979, no video terminal, no printer, hand assembly

My workplace setup in 1982: KIM-1, dual cassette, tv monitor, H14 printer, ASCII keyboard

1984, VT100 as videoterminal, what a progress!

Then a CP/M machine took over (a Spectravideo X’Press 738) with the same VT100 as terminal.

  • KIM-1
  • 8K RAM  in system case
  • 32K RAM in expansion case
  • Two ACIA 6850 serial
  • A PIA/VIA card with two 6820 PIA’s
  • Parallel ASCII keyboard with home made logic circuit
  • Video Display 32×32 uppercase characters on an analog TV
  • Dual cassette tape system with motor control
  • MDCR digtal cassette system in second expansion case
  • Radio Grafisch Display in second expansion case
  • Heathkit H14 matrix pinter, serial with RTS handshake via bitbanging RIOT port
  • VT100 Digital Equipment Video display unit VT100
  • Boot tape to load device drivers and Micro Ade (extended to 8K)
  • MICRO ADE assembler/editor, used for program development and article authoring
  • Microsoft Basic KB9 (not used often, nice study material!)
  • Pascal-M compiler and interpreter (mainly development and experiments, not for production)

First the KIM-1, I still have it, in working condition, in my private museum. Changes still visible, are a red acryl cover over the LED displays, a capacitor moved to the back to make it flat enough to fit the case I made and some supports to have it lay stable and safe on a table.

Why a KIM-1?

In 1977 I was reading in the electronics magazines about the revolution taking place: 8 bit microprocessors!
During my study I encountered Digital Equipment machines, PDP-8 in the lab, PDP-11 in the Mathematic Computer Science department, a Minc in Medical Physics group, my major.
The electronics department where I was doing an intern not only introduced to digital electronics and I helped them to introduce the Z80 to the instruments designed for laboratory experiments.
I learned assembler quickly, PDP-11 was a dream come true, the Z80 a bit of a nightmare but you could do so much with effort.

At the same time I started to write for the magazine Radio Bulletin, simple analog and digital circuits and continued to be an editor until 1987. I met Dick de Boer who was writing his famous Microprocessor articles and introduced the KIM-1 to the Dutch electronic engineers. So a KIM-1 with the very attractive 6502 was the logical choice for my first microprocessor system.

First case: memory, connectors, power supply

A KIM-1 itself was fun to learn with, but it quickly needed more; a permanent power supply, protection, easy to access connectors and interfaces for  a bus to have  more memory.
So the case seen in the next figure was built:

Power hungry, so lots of lineair power supplies with large cooling.

The first case I built from alu profiles contained the KIM-1, a backplane for 6 memory boards, a lot of power supplies (lineair, so heat was a problem!), a patch panel to access the expansion connector, cassette I/O, serial interface and various switches.

PCBs handmade, double sided!

Memory 2K RAM Card, BEM Bus Brutech Variant made by Hans Otten
Memory boards were made myself by drawing with Edding ink on the blank PCB, etching and drilling. Filled with 2102 RAM IC’s for 1K per board, it filled lower RAM of the KIM-1 $0400 – $13FF. The bus is a 31 pin DIN connector, based upon the BEM (Brutech) bus.

I bought two of this deck from Radio Service Twenthe, Den Haag, fascinating electroncis dump store!

The next thing I built was a video display unit. All TTL 74XX logic IC’s, a 2513 character generator, a AY-5-1013 character generator, an ASCII keyboard, display on TV 32×32 characters uppercase. RS232 input/output to the KIM-1.
On top of the VDU a dual cassette deck is shown. From the famous Dutch dump shop Radio Service Twente two audio cassette decks were bought, some audio amplifiers and power supply added, and a remote control circuit via a 6532 GPIO line (standard as in Micro Ade). Served me well for many years, in 2014 the decks strings were dried out and crumbled after many years of not being used.

Next was a real expansion cabinet with a long backplane for 32K memory with 8x 4K RAM card, 2114 based, Designed by me, published in Radio Bulletin and sold by Visser Assembling Electronics. BEM bus compatible.

4K SRAM card

4K SRAM card, Radio Bulletin September 1979 part 1  part 2

Production 4K RAM card

Prototype 4K RAM card, also hand drawn on the PCB!

In the expansion cabinet three slots were added for I/O. Two cards were designed by me and published in Radio Bulletin: an ACIA card for two 6850 Motorola ICs, and a PIA card for two PIAs, 6522 or 6520 or 6820 or 6821. I never used more than one ACIA and one PIA card. Shown are the prototype cards, in the article production quality PCBs were used.

PIA and VIA card design by Hans Otten June 1984 Radio Bulletin

ACIA Motorola 6850 by Hans Otten, 1983 Radio Bulletin

On one of the ACIAs a VT100 Digital Equipment terminal was connected, taking over from the bit banged serial interface and the homebuilt video display. ON the other ACIA a Heathkit H14 matrix printer was added, a mediocre but adequate printer.

Together with Micro Ade as assembler and editor, the dual cassette deck, 40K RAM In total, this was a nice machine! Until 1987, when I bought the Spectravideo X’Press 738 MSX and CP/M system, used for all my publishing activities.

A third expansion cabinet was built around 1983. It was driven by the PIA’s, the Radio Bulletin Grafisch Display was inside the cabinet, along with two MDCR Philips Digital cassette recorders, alo published in Radio Bulletin. The speed difference between Hypertape audio cassettes and 2400 baud MDCR speed was not that impressive.

Dirk Dral

EPROM card (Dirk Dral)

SYM-1 RAE-1 Reference manual, version of 1980

Read here: New manual uploaded: SYM-1 RAE-1 Reference manual, version of 1980. Scan by Rob Ward, thanks Rob!

The Best of Micro 3

Partial scan of The Best of Micro 3: AIM 65 SYM-1 KIM-1 part and General (6522).


Updates to KIM-1, AIM 65 and SYM-1 pages

With the help of users on the German Classic Computing forum I have added many manuals and magazines in German about those systems:

AIM 65 PC100 manuals
MICROMAG magazines
KIM-1 manuals in German

I also added books on the 6502 in general and on the KIM-1, SYM-1 and AIM 65 to the Books section.

Reading old magazines is always fun, from the period 1976 to 198x magazines were filled with articles on the 6502, the KIM-1 and other SBC’s.

German, Dutch and English magazine articles extracted here.
Kilobaud, Byte, Dr Dobbs and of course the dedicated 6502 User Notes, MICRO Journal and Compute are valuable sources, but look at the many magazines on this page!


Galactic Expansion Board

When I got a SYM-1 again, I needed to add ROMs, RAM and it would be nice to have the 1541 DOS finally operational (I had the documentation since 2000 and typed in the 1541 DOS source into TASM assembler source code).

I found this board on ebay and bought it. Well packaged, nice design with documentation.
It offers:
– RAM 32K for lower memory (62256)
– ROM for all known upper memory locations, loaded with Monotor, RAE, Basic and the 1541 DOS (28c256)
– power supply – audio interface and power switch and -5V
-SD2IEC interface with 16GB SD card
– a PIC18F27Q10 for glue logic and inverters for the IEC bus

A pity that the design make you loose access to the interface connectors.

Circuit diagram (from private communication with Bob from Galactic Studios)



C, Basic, RAE on the SYM-1

Wayne Parham of Parhamdata has an interesting page on his VIM-1 and SYM-1 systems.

He has written some interesting parts about MS Basic and CC65 C compiler for the SYM-1. reproduced here, credits go to Wayne Parham (the ‘I’ in the text).

Microsoft 8K Basic on the SYM-1

Most people think Microsoft got its start with Windows. Some know about MS-DOS and the story of its inception. Gates’ deal with IBM to put MS-DOS – and later Windows – on the IBM-PC is definitely the defining moment for Microsoft. It’s what launched them into the juggernaut of success they are today.

But the first Microsoft product was actually 8K BASIC. It was in all the popular microcomputers in the 1970s. They started off making it for the MITS Altair 8800 computer, which had an 8080 microprocessor. And when the 6502 became popular, Microsoft created a version for it. The Apple II, the Commodore Pet and the SYM-1 all had very similar versions of this 8K BASIC.

You can run simple BASIC programs with 4Kb of RAM, but a lot of the “really good programs” need more than that. One in particular that I always loved, was Star Trek. Any time I was at a computer club meeting where someone had a computer with more than 24Kb RAM, they’d be running that game. Just like you could expect to hear Led Zeppelin’s “Stairway to Heaven” or Lynyrd Skynyrd’s “Freebird” in every college dorm and at every party, if you went to a computer club meeting you would see Star Trek running on the head geek’s computer.

So now, with the Corsham Technologies memory board, my SYM-1 could be propelled to the pinnacle of geekdom and run Star Trek.

The problem is there are a lot of versions of the game and most don’t adhere to the 72 characters per line length limit. Some come close though. That’s a problem with many of the popular BASIC programs – there wasn’t a standard back then. Even the language was slightly different between platforms. You had Dartmouth BASIC, the original. Then you had Digital Equipment Corporation’s PDP-11 BASIC and BASIC-PLUS. You had Data General’s Business BASIC. Wang had their own BASIC. Basically, every platform had their own version of BASIC.

Microsoft’s entry of 8K BASIC sort of standardized the microcomputer industry, simply because it was so common. But that was still just another version of BASIC, and the popular “BASIC Computer Games” was actually written for DEC BASIC, so some stuff worked on 8K BASIC and some stuff didn’t.

So I set about finding all the BASIC programs I could find and seeing which would run on the SYM-1. Where I found line length past 72, I modified the program so it would fit. I usually just split the line into two lines. Sometimes, I needed to do a little more. But in most cases, the program is completely original. I’ve noted changes in a README.TXT file in the archive.

Some programs use trigonometric functions, which aren’t included in the 6502 version of Microsoft BASIC. They’re in the other versions of Microsoft BASIC but wouldn’t quite fit into 8K ROM for the 6502. So since these functions are rarely used, they were left out.

Synertek provided code for the TRIG function, which was to be installed in RAM, when needed. I’ve included a version of this code that resides at 9EC7-9FFF in the memory region just above the Monitor ROM. So if you have the CorshamTech memory board, be sure to enable this memory bank. You can then load the TRIG function before loading any BASIC programs that need it.

Alternatively, you can modify BASIC to include the TRIG function and recompile it. The BASIC Interpreter Source for cc65 is available on the pagetable site. It’s assembly code – not C – but the ca65 assembler included in the cc65 distribution will build it. More information on cc65 is shown below.

CC65: C on the SYM-1

When the SYM-1 was introduced, the C language wasn’t very popular. But it became hugely popular, both for systems programming and for things like embedded systems. It has some constructs that are very “close to the machine” that make it perfect for embedded systems. But it has some abstractions that make it easy to write higher-level systems too. So it’s a great language to use.

Still, it was not available for the SYM-1 in the 1970s or 1980s, or for that matter, even in the 1990s. By that time, I had long moved away from the SYM-1, putting it on the shelf for more capable systems. I often used C for embedded controllers in the 1980s, and I still do. I still use C++ for systems programming too. So when I brushed the dust off my SYM-1 and started looking around for stuff to do with it, I was really excited to find the cc65 compiler for the 6502.

I stumbled across the cc65 compiler by finding the BASIC sources mentioned above. The BASIC sources are assembly language, and they are built using the assembler (ca65) and linker (ld65) included with cc65.

I was super-excited to find this compiler, but my excitement paused a bit when I realized that it didn’t have all the files to support a SYM-1. There was memory configuration in the BASIC source distribution that could be used as a basis for the C language configuration though, and the documentation is really good for creating the code needed for a new target system. So I set about doing that.

The cc65 compiler will actually work on the SYM-1 – “right out of the box” – but it can’t support any I/O so it’s not particularly useful. A person can, however, compile a full-featured C program that operates in memory and leaves its results in memory. So all the heavy lifting has already been done by all the contributors of the cc65 project that have made it such an excellent compiler for the 6502.

All I needed to do to complete a port to the SYM-1 was to create a memory map and to provide functions for system I/O. I made functions to access all the SYM-1 I/O lines, the built-in “front panel” display and to direct read and write to the async port so console I/O will work. So I created the (asminc) map of all the important memory locations for monitor access and memory-mapped I/O, wrote little assembly functions for all the I/O and voilà! I had a SYM-1 port for cc65.

One of the first things I noticed – which was actually a no-brainer after seeing it – was that the compiled binary was much smaller when using primitive console functions like getchar(), putchar() and even puts() than it was when using functions that had formatting functionality. The reason is pretty obvious – Code that has to parse and interpret a format specifier is more complex than code that just operates on a single char, or that iterates through a char array. So for example, see the following two “Hello World” code snippets and notice the difference in the compiled executable binary size:

“Hello World” using puts() builds a 526 byte binary:

#include <stdio.h>;

void main (void)
   puts( "Hello World!" );

“Hello World” using printf() builds a 2368 byte binary:

#include <stdio.h>;

void main (void)
   printf( "Hello World!\n" );

These two programs provide the exact same output.
The second thing I noticed was equally obvious, after actually doing it. I made two memory configurations – one for the “stock” 4kb SYM-1 and a second for a SYM-1 fully populated with RAM. That second memory configuration only uses the bottom 32kb because it is contiguous. So but the stock 4kb configuration provides only 283 bytes of heap storage, whereas the 32kb configuration provides up to 28,187 bytes of heap. I found this by compiling the following program and linking it once using the sym1-4k.cfg file and a second time with the sym1-32k.cfg file. I’ve included both in the SYM-1 distribution of cc65. Of course, since the heap-test program uses printf(), the small memory configuration would have more heap available if it hadn’t.

Understand that the 283 byte limitation on the 4kb configuration is for heap storage. It’s not the total memory available. The compiler allocates memory for the stack, and you’ll probably do everything on the stack when writing a 4kb SYM-1 program. You can do a lot with a 4kb SYM-1 if you are careful with your programming style. I’ve included a few sample programs in the SYM-1 cc65 distribution archive that run just fine in 4kb.

Heap test program:

#include <stdio.h>;
#include <stdlib.h>;
#include <string.h>;

void main (void)
   char* buffer;
   int   heap_size;

   heap_size = _heapmaxavail();

   printf( "Heap available is %d bytes.\n", heap_size );

   buffer    = malloc( heap_size );
   memset( buffer, 0x00, sizeof(buffer) );

   if( buffer ) {
      puts( "Memory allocated." );
   else {
      puts( "Couldn't allocate memory." );


You’ll notice that the simple programs above all include , which is fine for console I/O but has no access to the Sym-specific I/O. For that, one would include .
After I had the port completed, I thought I’d better compile some other stuff to make sure it worked. I found a cool little “Adventure” program written by Jeff Tranter. He makes Apple clones and runs cc65 on them. So I compiled his Adventure program and it built and ran first try. I was excited both to know the cc65 compiler was working fine on the SYM-1 and also because I had a cool Adventure program now too! I also compiled Payton Byrd’s port of Wumpus. It requires the time function to randomize – and the SYM-1 doesn’t have a real-time clock – so I removed the time call and instead used an uninitialized int within a function. So just a very small change was needed to get that to compile too.

Now knowing the C compiler was working well, I decided to write a few more programs with it. I always liked John Conway’s life simulator, and it was popular on systems of the SYM-1 era. Even though there was a BASIC version of it, the speed of a compiled executable made a C version of the program more attractive. So I wrote a version of Life in C. Similarly, the Mandelbrot set images were sort of a 1980s thing, but the first ones were primitive ASCII renditions made on minicomputers in the 1970s, so I couldn’t resist but to write a fixed-point integer version of the Mandelbrot program in C. And finally – my pièce de résistance for cc65 on the SYM-1 – was to write a really nice big text adventure game. It doesn’t have the space for the full version of Zork, but it does have enough room for any of the three-part “slices.” Then it occurred to me that even better would be to write something totally new. So I set about making a map and a storyline and Jinx was born.

One more thing – an aside, really – for those of you interested in writing C programs for the SYM-1 or any platform using cc65, for that matter. This is especially true for those of you coding in C++. Most developers today are working with technologies like objects and dependency injection. These approaches are several generations away from the original C, and coding style is much different. What is considered “best practice” today is not really what works best in cc65. For example, most would frown upon using global variables and would prefer to pass variables between functions. But that requires stack operations – pushes and pops – which are expensive operations, especially for a register-limited eight-bit processor like the 6502.

Resident Assembler/Editor

Synertek provided a Resident Assembler/Editor, commonly abbreviated the RAE. It was a bit of an oddball, because Synertek didn’t appear to use it, themselves. It was a ghost of a product, and I can’t recall ever seeing any RAE listings other than those from members of the SYM-1 users group. Even Synertek’s documentation mentions their use of the Teledyn cross-assembler, TASM. The RAE was somewhat popular with members of the SYM-1 users group though.

Still, it was a nice little assembler and an interesting product, so I modified a couple of the programs from Synertek’s Technical Notes (which can be found in the documentation archive) so they would build in the RAE.

I probably should address the issue of transferring the files to the SYM-1. There’s no really easy way to do it, at least not “right out of the box.” You would think you could just copy-and-paste the contents of a program from some text editor like vi or notepad into a terminal emulator program and it would transfer essentially the same as typing it manually. The problem is the SYM-1 has to interpret every keystroke and determine what to do with it, so every character that comes across takes some processing time on the Sym. And since the serial interface has no handshaking signals, the flow must be throttled.

What I found is the transfer of HEX files (for object code) and the transfer of BASIC programs each have their own issues. For HEX files, one must simply throttle the speed of the nibbles, so that there is a slight delay after the two HEX digits that make up a byte are sent. This gives the monitor code time to parse the input and put it in memory. For BASIC, the speed of each character sent is one parameter and the speed of each line is another separate parameter. In other words, each character of a line is throttled by one amount, and then after the carriage return is sent, we have an additional delay. This lets BASIC parse the line and put its tokens into memory.

So I wrote a couple of little Python scripts to do this for me. One is ‘upload’, and the other is ‘upload_hex’. Use ‘upload’ to transfer BASIC files and use ‘upload_hex’ for HEX files. They each take one argument, which is the source file name. The communications port is defined in the code, itself. My system has a USB-to-RS-232 adapter defined as COM3, so that’s what is in the Python script. You can change yours to whatever you need it to be, or modify the script to pass it as a command line argument.

To transfer BASIC files, I first start up BASIC on the SYM-1 then I type ‘upload ‘ on the connected PC. To transfer object code, I first type ‘m 200’ and press enter on the SYM-1, and then I type ‘upload_hex ‘ on the connected PC. It’s a gomer-approach, but it’s pretty reliable. Only occasionally do I get an error – if I see ‘ER xx’ when sending HEX files, I know right away I must do it over – but it works about 80% of the time.

Compilers always write object code as BIN files, sometimes without an extension. If you don’t name ’em, a compiler will even call the file ‘a.out’ so but the point is it is raw binary. To transfer to the SYM-1, it needs to be a hexadecimal representation of the binary, so you will need to run ‘bin2hex’ on the compiled/linked program before transferring it. You can easily find ‘bin2hex’ on the internet.

Another option is this interesting new tool that may make connection with the SYM-1 easier:

Symtool – A tool for interaction with the SYM-1, by Lars Kellogg-Stedman
So you can use whichever upload tool is easiest for you.


SYMulator a SYM-1 emulator

SYMulator  is a working SYM-1 simulator by Andrew Dunn for Windows. It is based on a modified version of Daryl Rictor’s 65C02 simulator
Supported are Supermon 1.1 at $8000 (default after Reset) , Basic at $C000, and RAE at $B000.

The builtin Help will work in Windows 7, 8, 10 and higher with the enclosed WINHLP installer, see the Readme.txt

Download here.

SYM-1 Pascal and Forth

SYM-1 Pascal

Pascal manual

SYM-1 Forth

SK Forth 79 Users Guide
, PDF of Source listing