AIM 65 manuals

Under construction May 2022

AIM 65

Technical specifications
– Built-in full sized QWERTY keyboard
– 20 character alphanumeric LED display (16 segments)
– Integrated 20 character thermal printer
– 20mA current-loop serial interface (can be adapted to RS232)
– Expansion connector (KIM-1 compatible)
– Application connector with 6522 VIA chip
– 4 KB RAM
– 5 sockets for 4 KB ROM/EPROM chips

The AIM memory map is:
$0000-$9FFF: RAM (early Rockwell versions only had $0000-$0FFF on board).
$A000-$AFFF: I/O scratchpad memory; some areas can be made available for more RAM.
$B000-$CFFF: Optional Language ROMs (BASIC, Forth, PL/65, Pascal).
$D000-$DFFF: Optional Assembler or Mathpack
$E000-$FFFF: Firmware and monitor program

Rockwell produced the AIM 65 until 1985, and manufactured by Dynatem under license in early 1986 after Rockwell had ceased production. Though the Revision 4 AIM 65 is quite similar to earlier iterations, the subsequent Revision 5 hardware features a redesigned clock generator and support for newer RAM and ROM IC types which became available over the production lifespan of the AIM 65. Relative to Rockwell-manufactured examples, the Dynatem AIM 65 is quite rare. See the Manuals and Software page for circuit diagrams revisions.

Hardware bug on pin Z

There is a hardware bug in early AIM-65 boards. The problem was in rev 1 and rev 0 AIM boards, and it was definitely fixed on rev 4 boards Basically the RAM_R/W signal (pin Z on the Expansion connector) had the inverted Phase 2 clock NAND’ed with R/W. The SYM and AIM were both supposed to follow the KIM standard, but Rockwell got this one signal wrong.
Please note that this has to be solved in e.g. RAM expansion boards by generating this signal the correct way.

See the articles on the MC-65, a AIM 65 compatible system by the German magazine MC Die Microcomputer-zeitschrift


KIM-1 programs by Nils

Nils a.k.a. netzherpes typed in a number of KIM-1 programs to run on his PAL-1, the KIM-1 compatible clone.
Not only does he types them in in assembler, some even by contacting the original author!, tests the programs and also provides source and ready to run binaries or papertapes.
And he draws nice looking cover images!

On his github page he has the most recent versions and adds new programs regularly.
Also checkout his blog!

Here a summary of the programs:

Banner for KIM-1

KIM-1 Banner
by Jim Zuber

Download here!


You have 20 shots to detect a 3×1 ship on a 8×8 grid. The ship can be aligned horizontal, vertical or diagonal.
How to play: Enter the coordinated and fire (Button F). If you hit the ship, the mostright counter will jump to 01.
If you hit all 3 coordinates of the ship, you won, the display will show “dEAd” and the number of shots used.
(c) 1978 Roland Kushnier (orig)
(c) 1979 Jody Nelis (bugfix)

Download here!

Target 1 for KIM-1

Little shooting game for the KIM-1
June 18th, 1979
(C) Fer Weber

Download here!

Target 6 for KIM-1

The 6 column Version of Fer Webers Target1 Shooter Game (
Author Fer Weber
published in KIM Kenner 8 on 18.06.1979

Download here!

Telefonbuch for KIM-1

original title: “Datensuche”
by Herwig Feichtinger
(c) 1981 in Anwendungsbeispiele für den Mikroprozessor 6502

Download here!

Phonebook 2.0 for KIM-1

original title: “Datensuche”
by Herwig Feichtinger
(c) 1981 in Anwendungsbeispiele
für den Mikroprozessor 6502

Download here!

Pocket Calculator for KIM-1

by Siep de Vries, KIM Club The Netherlands

Download here!

Tunesmith for the KIM-1

(c) 1979 Anthony T. Scarpelli
found in micro 6/79

Download here!


a silly small Piano for your KIM-1
KIM Piano
(c) by Peter Engels 1979 *

plays whole notes from C to D
by pressing the buttons 0-F.
Download here!

LEDIP a text editor for the KIM-1

The author of the program, Kiumi Akingbehin, Professor at the Michigan University

Download here!

KIM-1 Dungeons and Dragons Dice Simulator

(c) 29.7.80 Myron A. Calhoun
Manhattan, KS

Download here!

TTY rapid Dump/Load

an extension to M.Gönners hex Loader by Bruce Nazarian

Located in Compute II June 1980
Download here!


‘Bob’ Leedom published another game called Baseball in the KIM user notes issue 16

Download here!


by Gino F. Silvestri
A Simon says game for the KIM-1

Download here!

KIM Venture walktrough

This is a walkthrough of one of the most amazing computer games in history.
KIMventure is a (colossal cave like) adventure game for the KIM-1 that fits in only 1 (ONE) KB of RAM. It offers 24 room to explore with a lot of traps and riddles to solve. It was programmed in 1979 by Robert Leedom with pen and paper (no assembler etc.)

Download here!

Hexpawn – another KIM-1 game from 1978

Download here!


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.


SYM-1 Memory Allocation

The SYM-1 had a comprehensive expansion strategy with both I/O (3 6522 PIAs and a 6532 RIOT) and memory. The board was shipped with 1kB RAM and this could be expanded “on-board” to 8 2114 Static RAM chips to 4kB onboard. (It also allowed write protect of this extra RAM in 1kB blocks). There was also provided four 24pin ROM sockets. As shipped it had its monitor (Supermon 1.0) in a 4kB block from $8000 to $8FFF. The other three sockets were pre-wired to accept 2kB ROMs, or EPROMs.

To be able to do this configuration after shipping meant providing some ROM selection to be done in the factory but to also allow later configuration in the field. A system of address decoders (74LS145) were used that were open collector outputs and options to “OR” these together to be able to map ROMs from 2kB, 4kB and 8kB into the upper memory spaces. RAE and BASIC were both available as two 4kB ROMs or as single 8kB ROMs.

Here is an example memory map of the upper 32kB

$8000-8FFF Supermon                                                       4kB
$9000-9FFF Supermon Expansion or Extensions                               4kB
$A000-AFFF Memory Mapped I/O and 128B of System RAM (Not usable as ROM)   4kB
$B000-BFFF Resident Assembler and Editor (RAE)                            4kB
$E000-EFFF (This has separated 4kB entries *, and note correction below ) 4kB
$C000-DFFF Microsoft BASIC                                                8kB
$F000-FFFF extension area (must include ROM startup Vector)               4kB

In the early 1980’s the 2716 EPROM (2kB) was a popular and easy to use chip and was often used to expand the SYM-1 ROM memory. These days the 2764 EPROM (8kB) is about the same numerical price or cheaper in quantity, and of course much cheaper given inflation. However a 2764 has 28 pins and not 100% compatible with the 24pin onboard sockets, but a good proposition having 8kB capacity means RAE or BASIC or Supermon + extensions could fit into a single chip (and we could fill the upper 28kB with ROM if desired). The old 2364 masked ROMs had only 24 pins, but as soon as the EPROM version is chosen it has extra pins for program enable and provision of the programming voltage (eg 12.5V etc)To get around this a riser board was made that has a 24 pin plug below and a 28 pin DIL socket on top, with the leads routed to reproduce the pin-outs functionality of a 2364 masked ROM.

Because the pin-outs of a modern 2764 are about 85% identical to a 24pin 2364 only small changes needed to be made to re-route the various signals. This is outlined in another page here XXXXX. The trick after “burning” the EPROM is getting the memory map links set up so that the EPROM appears in the right memory locations. The information in the manual is very helpful and accurate, but organised that well to instantly make clear what needs to be done. Below is the array of connections (and PCB breaks) used to implement the system above.

The jumpers and PCB Breaks list:

C to 1                  Allows RAE EPROM access to A11	                    ROM U22
E to 4 and G to 4       Allows Supermon +Extensions EPROM and               ROM U20
                        RAE Access to A12	
J to 10 and J to 9      Adds CS for $9000 and $9800 Extensions ROM          ROM U20
(9&10 are switched to J) 	
K to 11	                CS for Extra ROM (not used here, eg BASIC at $C000) ROM U21
L to 46,  L to 47, 
L to 15 and  L to 16	CS for RAE EPROM, $B000-BFFF and $E000-EFFF         ROM U22
Cut PCB at C // 2       disconnect S21 pin 18 from GND                      ROM U22
Cut PCB at E // 3       disconnect S02 pin 21 from  GND                     ROM U20
Cut PCB at G // 5 or 6	disonnects  S22 pin 21 from 5V	                    ROM U22

This is essentially enabling the high address lines A11 and A12 for the bigger 8kB EPROMS and to also free the same lines from being tied to GND or 5V (for the original 2716 chip enable OE or CS pins).

* NB: RAE Addressing QUIRK There is a quirk in the SYM-1 ROM slots. Where A12 goes to the U20 Supermon chip correctly, there is a mistake for the U22 chip position that I chose for the RAE chip. It has the A12 line inverted. What this meant was I had to split the ROM image for RAE in half and reverse their position in the 8kB ROM. So $B000-BFFF was in the second half of the EPROM and $E000-EFFF was in the first half of the EPROM. In the RAE Notes it talks of using a spare inverter on the SYM-1 board to do this inversion of A12. It would appear they did not know this themselves when they created their own ROMs. However we can simply correct for it by reversing the order of the 4 blocks and it works fine. G B000 works to run RAE and it is ok after that. I will try to add a RAE version for 2764 EPROM in the files section.


SYM-1 Memory Expansion

Memory was expensive in the days when the SYM-1 was released. The boards were shipped with 1kB of RAM (2 “2114” of 4bits by 1024), but could have another 6 of 2114s to be plugged in without any extra hardware required. The memory chips were not only expensive but the extra hardware of the PCB and sockets etc ramped up the price very quickly. I dutifully bought some 32kB Static RAM chips in 28pin DIL format and was setting about making a memory expansion board that could also accommodate 2764’s to provide 8kB EPROM sockets, again 28DIL packages. I was half way through failing on this when I found this site Corsham Technologies where a full 64kB of RAM could be bought in a plug in and go format for the SYM-1 (and AIM and KIM). It could be paged in or out in 4kB blocks with a 16bit DIP switch, to work around where the SBC’s existing RAM, ROMS or I/O were paged in. This was simply amazing!! I ordered one and it is the most highly recommended and easiest part of this project to complete. Just buy it, flick some DIP switches and plug it in. Bob Applegate has a fantastic design here. Using this I could soft load ROM images such as MS BASIC ($C000-DFFF) and RAE (Resident Assembler and Editor) ($B000-BFFF, $E000-$EFFF) into RAM and begin to feel I had a really worthwhile project on my hands.

This is the board attached to the expansion E-Connector (raw Address and data bus etc). The onboard 4kB of RAM is still plugged in and the expansion RAM is switched out of that range. I have used two sockets here back to back only because I had them. I originally wanted to build a back plane for my expansion boards to plug into. So I asked Bob not to solder the connector socket onto the board as he normally did. However when I thought it through, while I could flip the board over for a back plane insertion, unless it was also upside down, the connections were mirrored 🙁 So I soldered two plugs together as Gender Bender hack to preserve Bob’s beautiful board, but still able to connect it up. Don’t much around and follow Bob’s full design and just buy with the socket soldered on.

Synertek used a Paper Tape format to store data to a 1″ wide paper tape punch. These could be found on the side of ASR-33 Teletypes along with a paper tape reader. These machines were a hackers delight in the day, and were treasured. However they also ran at 300baud, or about 30 character a second, so the Synertek system was able to run at 300Baud, but sadly no faster. The format had a checksum at the end of each line and most likely while the 6502 can calculate and check the checksum at 300Baud, it could not cope if the baud rate was any higher. So when I got my expansion RAM and wrote a Python script to turn Binary images into Paper Tape format, and tried to load the paper tape versions 8kB ROM images from SYM-1 Resources at I found the speed was really painful. The 300Baud was bad enough, but because each byte was sent as two hexadecimal characters, it made it twice as hard to bear. The second problem was the GTK-Term program that had served well up until then could not stream that many characters as characters and would always stall mid load. The answer was to use the MiniTerm Serial program that is found in the Python suite. Here is the command to trigger it off

First of all install the following:

sudo apt-get install python-serial

and then begin the TTY session with:

python3 -m /dev/ttyUSB0 300

This did not stall on loading the Paper Tape files at 24,576 bytes long. (Nearly 3 times longer than the original ROM image!!!). Once the Python terminal was running and the SYM-1 prompt initialized at 300Baud (reset and press Q), LP could typed and it would be expecting the paper tape reader to begin feeding in the data. To get the Python terminal to send raw bytes from the .ptape, CTRL-T was pressed and then CTRL-U, which prompted for the filename. Press the Enter key and go away for 20-30 minutes while it loaded. At the end G C000 would start BASIC or if you loaded RAE, G B000. One neat thing about the Paper Tape format was that each line contained the address for where the following (up to 16) bytes were to go. So while the RAE ROM is split over 2 of 4kB blocks, they are not contiguous. So half of it loads into $B000-BFFF, and the second half loads into $E000-EFFF. As long as the paper tape is configured properly, this jump is taken care of automatically. However when I was burning this into an EPROM, I found there is more to add to this story. (Memory Allocation)

Another major hurdle was getting the 28pin EPROMs to work with the 24pin sockets on the SYM-1. Synertek had envisaged using 8kB ROMs, and with one chip enable, there is enough pins in a 24 DIP socket to handle 8kB. However an EPROM needs a programming pin and pin to supply the programming voltage, in this case 12.5V. So and 8kB EPROM is usually fitted into a 28pin package. I wanted to have RAE in ROM on the board, so I really wanted to be able use those 2764 EPROMs.

I found an image of how to map 28pin EPROM to 24pin ROM and made one up using perf-board (Vero) and some thin wire-wrap wire.

Extensions to SYM-1 Monitor

Saving and Loading, S3 and L3

The SYM-1 SBC was at the cutting edge of the growth of the 8-bit micro computer. It had very good expansion capabilities for I/O but initially relied heavily on the Cassette Recorder as the medium for saving and loading programs. When programs were in the order of 10 of thousands of bytes long this was a practical, and very economical solution of the day (C:1975-1980). However cassette tapes were not particularly reliable or fast. Worst of all they required considerable organisation to be finding and playing back the right tape for the right program.

The common experience of having a Disk Filing System was probably about 5-10 years off when the SYM-1 hit the shops C;1978. One of the more robust parts of its design was a comprehensive Monitor (Mon1.1) program that allowed the user to manually enter and edit programs in Hex format. It also allowed for 8kB language ROMs, such as Microsoft Basic and the Resident Assembler and Editor (RAE) to be onboard and in ROM. For many users to switch the computer on and have these major packages instantly available were game changers. These packages also very efficiently made extensive use of the subroutines built into the monitor program. The SYM-1 used a pressure-pad hexadecimal keyboard and 7-segment digital display. However a terminal could be hooked up to the board as well and which ever input, hex keyboard or TTY, was detected as active first, it took over the interactions with the user. This required the hexadecimal keyboard to generate standard ASCII tokens for commands and data, so this made swapping to a full ASCII keyboard and display just a matter of changing a few vectors on initialisation. It also meant it was seamless to have full ASCII interaction with BASIC and RAE as well.

One of the features that built into the monitor is vectoring of “unrecognised command” errors that are generated when undefined commands are entered. The monitor passes control through a vector before reporting them to the user. If the vector is taken over, unrecognised commands can be diverted to create new commands that have the same style, format and structure as the existing commands. The extensions then look and feel like they were always in the design. The commands to save and load data have S1 (Kim format) and S2 (SYM-1 high speed format) and using the latter as an example worked like this:

.S2 xx,aaaa,bbbb where xx was the index number of the program, aaaa and bbbb was the start address and end address respectively of a block of code to be saved. Notably this meta data was also saved as part of the tape data structure.

.L2 xx allowed the program with the index number xx to be loaded automatically back to its original address.

.L2 xx,aaaa allowed the loading/starting point in memory to be chosen.

This was a natural extension to the Mega Filing System, so the S3/L3 commands were created. It meant binary chunks of memory contents could be saved as files and reloaded to the original address or a new address. To do this the first two bytes of all saved files contain the default 16bit address they were saved from, and in many cases, most likely to be reloaded back to that address. This means a saved file will always be seen by the Mega 2560 as two bytes bigger than the memory block used to create it. Why do this? Well a long term goal is to be able create a library function where unknown commands are also looked up as files and can be executed by simply typing their filename. The program would be loaded at the default address, and execution begun at the start of the file. This would allow extension of commands and memory re-use (eg sequences of programs could be run in the same memory space, others might be semi permanent etc). A related goal was have all filing transactions run in raw binary and not have the overhead of trapping trigger characters in ASCII streams etc and sending everything in hexadecimal pairs in ASCII. Going to the trouble to compute lengths of files where ever possible and only using ASCII streams for displaying purposes.

One of the challenges was how to create a file index or a name? I chose to simply turn the 16 bit number into 4 hexadecimal ASCII characters and use that as the name. This requires the age old hacker skills of creatively using 0123456789ABCDEF to create memorable four character names (with a bit more than 64000 possibilities, it should be sufficient for the average 6502 hacker). Below is an example of a 16 byte file saved from $200-20F and called C0DD (ie C-Zero-DD).

This may be best shown by a self explanatory run through a demo (user input purple, explanation in green):

It also means larger binary images can be conveniently loaded such as Microsoft Basic:

This 8k image loaded in under 3 seconds and would have been quicker without the loading progress indicators. So about 24kBits/Sec.

Or loading and then running the famous Microchess from the KiIM-1 stable

SYM-1 Mega Filing System

The SYM-1 was a SBC, built by Synertek from around 1979 when it started to become popular, and while the name does not roll off the tongue of people who become nostalgic about computers of this era, due to the quality of its design and build, it was a remarkably influential system. It, and its older brother, the KIM-1 from MOS Technology, attracted many very competent developers in the hacker community (well, even the Hollywood word NERD had just been invented by then, and of course, with 20-20 hindsight we can recognise these were genuine 100% Hackers at the time) who went on over time to develop a number of disk operating systems to free the SYM-1 from its native Audio Cassette interface.

The SYM-1 had a high-speed cassette interface and was quite reliable (well, as good as any cassette recorder could be, eg good brands such as Hitachi, were very reliable), but lacked the speed and indexed directory access of disc drives. Going over the literature around this time looking for clues on how to expand my SYM-1 board to this level of convenience, the articles are firmly set in the boundary where 8inch Floppy drives were being upstaged by 5.25inch Floppy drives. (Wikipedia: History of Floppy Drives) Having two floppy drives, one for system files and the other for data files was very fashionable. IDE Hard Drives with capacities around the 20-30Mbyte were also becoming available but were out of the price range for most hackers of the day. Never the less, the trend was becoming obvious. Full height Shugart SA800s would have to give way to the Shugart SA-400, and later, low profile half-height, double sided systems, such as made by Mitsubishi etc would ascend, and finally the 3.5inch rigid case, but floppy medium, would claim supremacy. However even back in 1980, it was easy to see the capacity plus speed of hard drives would win in the end.

So there are a couple of designs for IDE interfaces and DFSs for the SYM-1 and I have bought an IDE to SD-Card interface to maybe try to get one working. But for the moment the thought of recreating a full IDE interface was too daunting and not really meeting my aim to dabble back in the world of assembly language and bits/bytes at hard metal level.

An article that caught my eye during this research described using an Arduino and SD-Card combo to do a handshake parallel interface to a retro computer to enable saving, loading and managing files. I liked the statement that no error checking was built in as it was so reliable. I have since lost track of the article and cannot find it on the Internet. If anyone can enlighten me as to that, or other articles that are relevant, I would like to be able to suitably acknowledge their work as well. So please leave it in the comments below. It would be hard call for me to bit bash directly to an SD-Card, and the thought of trying to emulate any sort of MS-DOS was overwhelming. Though others have done this very successfully.

The SYM-1 was designed by Synertek and the Monitor program was 4kBytes and was big for its day (two to four times bigger than other evaluation board SBCs). The company also distributed a version of the 6502 Microsoft BASIC in a 8kByte ROM as well as a Resident Assembler and Editor (RAE) also in an 8kByte ROM. (Other languages such as Forth and Pascal were also mentioned, but not as well documented). These two main offerings were available in 2 by 4kB ROMs or a single 8kB ROM. After completing the 64kB RAM upgrade (see my other pages on this project) I was able to soft load both these images into SYM-1 memory and run them successfully. I was very keen on getting the RAE up and running as it was the main focus of the serious Hackers in the late 1970s that were adding disk storage to their SYM-1s. I had also used the MS BASIC extensively in the early 1980s, and after selling my SYM-1 to buy an Acorn BBC 32kB and used its BBC BASIC, I was never, ever seriously returning to MS BASIC, it was a mongrel. Admittedly BBC BASIC was a 16kB creation, but it just had so much more to offer. However the RAE (complete with Macros and Conditional Assembly for a start…) for the SYM-1 was like a jewel frozen in time that I was keen to explore. Playing around with Arduino SBCs only fuelled this desire to bash bare metal.

There was a spare Arduino Mega 2560 lying around in my parts drawer and I had a WiFi and SD-Card interface to put on it. The thought of being able to communicate with the SYM-1 to the Mega to the WiFi was a very attractive goal (dream?). An 8bit port on the SYM-1, and one on the Mega were identified and connected up. The SYM-1 side used a 6522 PIA port and a second port on the same U28 chip provided 2 bits for the hand shaking signals. Likewise the Mega used one port and 2 bits of another port to provide its hand shake. At some stage it would be more elegant to use the 6522 CA0 and CA1 pins for the handshake seeing that is one feature they were originally designed include. Saving on I/O pins is not a high priority at the moment, however the KISS principle is.

The initial aim was to use RAE to write the filing system, however this proved difficult due to the primitive nature of the RAE editor (no WYSIWYG there at all, just line numbers and the backspace key) and the fact that RAE loading and saving was mainly set up to use audio cassette tape machines. Hunting eBay and local op-shops for an old recorder proved fruitless, and writing a cassette tape emulator on an Arduino just seemed a dead end. Why not just just go for it? So thinking big and using the online 6502 Assembler (Online 6502 Assembler, Masswerk) fairly quick progress was made. This is a truly excellent bit of software.

The basics of a filing system that covered my immediate needs was to be able to Save RAE files (create), Load RAE files (retrieve), list a Directory of files (inspect entries), and Delete files from the directory. Some very simple safeguards and error reporting was also required to avoid mistakes, and the system locking up. So when saving a file, it was prudent to check if the file already existed and warn the user that continuing would cause an “overwriting” of an existing file, likewise when deleting a file a similar warning should be given that a file was about to be destroyed. Trying to load a file that did not exist, or delete a file that did not exist also needed to be alerted to the user. While it would be fun to go down the rabbit hole of sub-directories and navigating them, the simplicity of a sound working system would do for the moment. High on the list of further improvements would be dumping a file showing both hex and ASCII, as well as being able to save a binary file from anywhere in memory, and mirror that with loading a binary file anywhere into memory. Running programs by filename would be excellent as well.

So at the moment the Mega FS 2.3 is working and meeting my minimal requirements, hence this write up. Here are a few screen grabs to illustrate it in action. Latest Version 1.9 has ANSII ESC colours integrated as well, some on the 6502 side (yellow/purple start up banner) and some on the Mega2560 (directory listing cyan/red, user inputs are purple, explanations are green).

The above shows the entry into RAE from the Sym-1 monitor command. The monitor prompts with a simple “.”, very modest!! Entry to the RAE begins at $B000, and the extension MegaFS code is triggered by a CTRL-C to the monitor and .G 9000. This links in three RAE Disk Commands, quietly embedded into the original RAE program as vector locations for future expansion to a disk based filing system. After all these folk were very forward thinking and designed versatile systems, so why not? None of the Apple II style detecting characters in the screen and keyboard streams to trigger its DOS commands. Changing these vectors after the main program was initialised allows them to be automatically redirected to use my extension code. (RAE commands generally only require the first two letters of a word, the rest is skipped over eg EN and ENTER are the same command, the TER is redundant).

DC (Disk Command) : There are two variations to the DC command. The LI variation is shown above “DC LI” and it simply returns a listing of the file names and their sizes on the SD-Card. The Arduino SD library is used extensively in this design, and basically does all the heavy lifting in managing the files on the SD-Card. Amazing stuff!!! Folders are identified but are not accessible. The listing is formatted into three columns but not sorted in anyway.

Entering the EPROM at $9000 not only sets up the vectors into the extension code, but also resets the work spaces for RAE to better utilize the 32kB RAM. The Sym-1 could originally be expanded on-board by adding 4kB of RAM (eight of 2114s, 1k by 4 bits), and the ROM startup values of RAE reflect this, so need redefining when 32kB is available.

LO : This LOads a file from the SD-Card into the program space of the RAE. It loads just the program so that programs could be sequentially loaded and assembled if required later on ie merged.

EN : This ENters a file into the SD-Card directory, in other words “saves” a file.

The above graphic shows a program called LOOP1.RAE being LOaded. This tiny program begins a $200 and ends at $235, so the length is $36 bytes. The program is listed to the VDU with the PRint command. To illustrate the safety prompts, the file is then saved back under its original name, and a “YN?” prompt ensues to alert the user an overwrite is about to occur. Pressing “N” aborts the save, and as we can see, responding with a “Y” allows the overwrite to proceed. Finally, if the filename does not exist, the save proceeds without any prompting.

Now we will have a look at the second variation on a DC command, DE (shorthand for DELETE) to allow us to tidy up the files on the SD Card from time to time. (NB This Version 1.18 or 1.8, ie no coloured file names etc)

The above shows the state of the Directory (DC LI) before a file, there is a deliberate incorrect attempt at the filename Loop.RAE to demonstrate reporting of non-existing filenames. LOOP1.RAE is identified and the process of deletion begun but aborted with N, and retrying LOOP1.RAE is then finally deleted, with a response of Y. A directory listing is then shown with the file deleted. It also uses simple feedback if a user tries to delete a file that does not exist, “N/A!”, and if they correctly identify the file, that it is indeed what they want to delete, with the prompt “Y/N?”.

Another command whish is very useful to analyse what is going on with files is to be able to dump the hexadecimal version of the file. This function has extended the Disk Command DC with a HD, or HexaDecimal command. Note that the filing system now saves a default loading address, using the first two bytes contained in the file. When the file is dumped to HexaDecimal this is shown before the data contained within the file. RAE ignores this information and loads the file to the memory location as set by its memory allocation pointers (usually $0200). Whereas the monitor can use it or change it to another location. The reason for this will be explained further in the pages on the Monitor saving and load (S3 xx,yy,z and L3 xx) extensions.

This very simple system is a huge jump in convenience over implementing any sort of audio cassette filing system (whether a real recorder, or emulated by an Arduino). The Wi-Fi system of the Arduino lies dormant at the moment. The grand plan would be to have the hand shake serviced by none other than the King of the SBC’s, a Raspberry Pi 4 that has WiFi and will also enable file sharing through handshak

Latest Version 2.3 has ANSII ESC colours integrated as well, some on the 6502 side (yellow/purple start up banner) and some on the Mega2560 (directory listing cyan/red).e across the PIO. That way the RPi could run the terminal program, provide the online 6502 Assembler, save object files into the shared folder and they could be directly loaded into the Sym-1 with a Disk Command for directly loading binary files….. Sweet!!!