MC-65 AIM65 compatible

An AIM65 compatible 65C02 CPU based computer, the MC-65. With a 6532, 6522, terminal I/O, cassette interface, and in theory possible to run the original AIM 65 ROMs.

For AIM 65 ROMS and manuals, see the AIM 65 pages!


Large update!

While I was working on my KIM-1 emulator, I did a lot of research in my own archive and the internet and found this website was not showing all I have offline.
So lots of updates, enhancements, scans, software, magazines added, before the programming continues on the emulator!
Read More


RB Specials

When I was an editor at Radio Bulletin we published several specials. Some were additions to the magazine, two specials were on sale.

RB CB Special 1980. The early KIM-1 articles by Dick de Boer.
RB CB special inhoud
De Keuze van een Personal Computer, Hans Otten
rbspecialmicrocomputers, D.M. de Boer
EPROM programmeerapparaat met de KIM, J.M. v.d. Peijl
Grafisch TV-display, D.M> de Boer
Mastermind op de KIM, J.M. v.d. Peijl
Morse-decodering met de KIM, M.B. Immerzaal
Programmeren, stap voor stap
Zero page shifter. D.M. de Boer
Automatische registeruitlezing, D.M. de Boer
CB Special 1982. KIM uitbreidingen Paul de Beer en Hans Otten.
Inhoud CB Special
EPROM programmeerapparaat PET en KIM, J.M. v.d. Peijl, P.G.J. de Beer
Geheugenuitbreiding voor 6502-systemen, H.J.C. Otten, P.G.J. de Beer
Mini-assembler voorde 6502, M. Dohmen, R. Koekoek
ASCII-toetsenbord UART-schakeling Baudrate generator, H.J.C. Otten
5V 20A Voeding voor microprocessorsystemen, Manudax
AMI-COS getest, overdruk Radio Bulletin Sepember 1980, H.J.C. Otten
De microprocessor van morgen, P.G.J. de Beer, H.J.C. Otten
uprofessioneel bijlage 1980, BEM Brutech

RM 65

Datasheets of all available RM 65modules are described in Chapter 9 of the 1984 Synertek Databook

User manuals of some RM modules:
Single Board Computer (SBC) Module User’s Guide
16K PROM ROM Module User’s Manual
32K Dynamic RAM Module User’s Guide
8K Static RAM User’s Manual
eneral Purpose Input Output and Timer Module Users Manual
Run-time BASIC User’s Manual

RM 65 32K Dynamic RAM module

RM 65 Floppy Disk Controller Module

Floppy Disk Controller Module User’s Manual
RM 65 Floppy disk Controller Module User’s manual

RM 65 CRT Controller

Configuration Guide Rockwell Modular Microcomputer Products

Software Preparation System Development Configurations

Photos from

Development System

RM 65 to AIM 65 Interface card

RM65 interface on AIM 65 expansion connector

Interface card between RM65 and AIM 65

General Purpose I/O Timer interface

Rear of General Purpose I/O Time interface card

RM65 top

Cage with cards

CRT Controller

FDC Controller

Rear of Floppy disk interface card

32K RAM Memory card

Rear of 32K RAM memory card


My AIM 65s

My AIM 65 collection, a PC100 Siemens OEM with custom software and a German manual, and a stock AIM 65 with full documentation.


Other, AIM 65/40 information

Application Notes, datasheets, other articles, AIM 65/40 information

Datasheet AIM 65 A65-100 A65-400

Datasheet AIM 65/40 A65/40-2000 -3000 -4000 -5000

RS-232C Interface for AIM 65

A CRT Monitor or TV Interface for AIM 65

Printer Control with the R6522 VIA

Optimizing Usage of the AIM 65 I/O block

Preparing AIM 65 BASIC program for PROM ROM Operation

AIM 65 enclosure

How to replace a printerhead for the AIM 65.

AIM Expansion Motherboard

AIM 65 Program Timer

AIM 65 PROM Programmer and CO-ED Module

AIM 65 Laboratory Manual And Study Guide By Leo Scanlon


(Part No. A65-905-08) with 8K CMOS RAM (4x2K) and four sockets for 4 x 4K PROM/ROM for use with the Rockwell packaged 500 Series of desktop microcomputers or any AIM 65 board-level microcomputer with Buffer Module. Document No. 29000D98

Many applications of AIM 65 microcomputers, particularly in test equipment, instrumentation, monitors, analyzers or controllers, require that the resident application software or fixed parametric data be changed periodically. This may occur because the item under test or being controlled has been changed, or parameter values have been revised. For OEM installations, the change may be required to customize the system (or different customers).
The AIM 65 Memory Cartridge system is an economical and convenient method for expanding the memory of an AIM 65 microcomputer. The cartridges are designed for use with the Rockwell packaged 500 Series of desktop microcomputers, but may also be used with any AIM 65 board-level microcomputer. This Memory Cartridge is ideal to be used for swapping to the Buffer Module needed to connect to the AIM 65 Master Module. This Memory Cartridge has 8K CMOS RAM and the PROM/ROM part is unpopulated for complete user flexibility.
Rugged injection molded plastic covers the Memory Cartridge complementing the AIM 65 Enclosure in color, texture and sturdiness. A Memory Cartridge plugs vertically into the Buffer Module which is needed immediately behind the microcomputer enclosure to require a minimum of area in desktop applications. A recessed label area on the Memory Cartridge cover allows configuration information to be neatly added in an area visible to the operator (see picture). Address decoding required by the different cartridges is accomplished automatically without user intervention.

• Preconfigured Memory Cartridge Combination RAM and PROM/ROM sockets
• Convenient Memory Cartridge plug-in installation to Buffer Module (needed)
• Use with any AIM 65 500 Series Desktop Microcomputer
• Compatible with A65-006 enclosure and power supply
• Cartridges are fully assembled and tested

AIM 65 Memory Cartridge

Bubble Memory Products

AIM-65 Bubble Memory

Bubble memory R3288-11 ROM
Cubit 6516 Programmer

Cubit 6516 Eprom Programmer manual and photos

AIM 65 Manuals and software

User’s Guide
Contains the monitor and optional assembler ROM functionality, see also below for Monitor listings and ROMs.

Programming Manual

Hardware Manual

Circuit diagram

Large format scan of Circuit diagram AIM 65 Poster

AIM 65 Schematic Poster revision 4
Circuit diagram PDF format Revision 0
Circuit diagram PDF format Revision 1
Circuit diagram PDF format Revision 2
Circuit diagram PDF format Revision 3
Circuit diagram PDF format Revision 4
Circuit diagram PDF format Revision 5

Dynatem took over AIM 65 production via a license from Rockwell after 1986.
Here a document describing revisions of the board.

Reference card

Basic Language Reference manual in PDF format

Basic Language Reference manual in text format
First Basic ROM R3225-11 B000
Second Basic ROM R3226-11 C000 part R32J1-11
See Create your own Version of Microsoft BASIC for 6502 and Microsoft BASIC for 6502 for a commented assembler source for AIM 65 Basic.
GW Basic 2.1 for AIM 65 and PC100 ROM 1 B000, ROM 2 C000 ROM 3 D000
GW Basic 2.3 for AIM 65 and PC100 ROM 1 B000, ROM 2 C000 ROM 3 D000
Dump of the Basic ROMS in my Siemens PC100 by Philippe

Basic reference card AIM 65

AIM 65 Forth Manual for the AIM65, V1.3, first two chapters, overview, installation and start for AIM 65

AIM 65 Forth V1.4 Manual for the AIM 65/40, after chapter 2 is this manual also applicable also to AIM 65

Compact A65-050 AIM Forth ROMS description of all Forth words

First Forth ROM V1.3 AIM 65-050 B000
Second Forth ROM AIM 65-050 C000
Math Package A65-040 D000, floating point words

Monitor program listing in PDF format

Monitor and assembler are described in the AIM 65 User’s Guide.
Monitor ROM R3222 E000
Monitor ROM R3223-11 F000
Assembler ROM R3224 D000
Monitor ROM Dynatem E000 Only change is copyright string Rockwell to Dynatem
Monitor ROM Dynatem F000 identical to R3233
Monitor source in AIM 65 assembler format
Monitor V1.1 source in TASM format

PL/65 Manual in PDF format

PL/65 Manual in text format
PL/65 disassembly, no comments
PL/65 V1.0 ROM 1 B000
PL/65 V1.0 ROM 2 C000

Instant Pascal manual

Instant Pascal, an interactive Pascal variant “INSTANT PASCAL(TM) (C)1981 MELVIN E. CONWAY”
5 ROMS, available in hex format. See the manual how to install, it needs an external expansion adapter, see the Other AIM 65 page.

Background of Instant Pascal

By Mel Conway

I proposed to Rockwell to build an “Instant Pascal” trainer to run on the AIM-65, and the proposal was accepted. The AIM-65 was a single-board computer with an 8-bit Rockwell 6502 (the processor used in the Apple II), 4K bytes (that’s right, 4096 bytes) of internal “random-access” memory (RAM), up to 20K bytes of on-board “read-only” memory (ROM), and various byte-at-a-time input-output possibilities. The user interface consisted of a teletype-like keyboard, a single-line 20-position LED alphanumeric display, and a thermal strip printer with 20 characters per line. (The only widely used external storage was an audio cassette recorder.) The intention was that the user would get Instant Pascal in the form of a set of ROMs. You plug these ROMs into the AIM-65 and you have a Pascal trainer.

The AIM-65 had multiple hardware limitations. The major one, of course, was the 4K RAM. But the single-line display wasn’t helpful. Clearly, any Pascal editor would have to be a “line” editor, not a “screen” editor. The traditional solution would have been to prepare a program in four steps: (1) the entry step, in which you prepare a source tape; (2) the edit step, in which you modify your source program by doing tape-to-tape copies under control of the keyboard and display; (3) the compile step, in which you read a source tape and write an object tape; and (4) the run step, in which you load the object tape and execute it. Debugging is clearly a problem because you have to have both the source program in view (so you can find and fix your mistakes) and the object program in memory (so the program can run). How can you do that in 4K of memory? And how are you going to do all four (or five, if there is a separate debugger) steps under control of 20K of ROM? I had no intention of building a language trainer that way.

There was an alternative: to store the Pascal source code in the 4K RAM and interpret it directly. Waterloo Pascal1 did that. They had the right idea, but directly interpreting source code made it really slow compared to BASIC, which was the alternative at the time. I was, frankly, relieved to discover how slow Waterloo Pascal was, because I already had the outline of another approach.

The Approach

As with Waterloo Pascal, my solution to eliminating the build-run dissonance was a single internal representation of the program that stayed in RAM. It had to be compact, efficiently interpretable, and readily translatable back to Pascal source so that no source program needed to be stored. The approach I took is today called a “tokenized” representation of the Pascal program. The internal representation of the Pascal program was syntactically correct Pascal: I specified the token language using the formal Pascal syntax. This assured syntactic similarity between external and internal representations of a program. I put one constraint on the user: text had to be entered in “prettyprint” form (no indenting necessary), one line per prettyprint line. Fortunately, this was not a source of complaint, because entering code this way was considered to be good practice; thus this most serious limitation was reframed as a feature. The prettyprint input constraint permitted line-by-line translation into token form (and local syntax checking, with immediate feedback), and there was no need to store more than one line of Pascal text internally.

The parts of the program consisted of (1) a single-line source-code tokenizer/syntax checker (“forward translator” from keyboard to RAM); (2) its reverse, a single-line token-to-source “backward translator” from RAM to printer; and (3) a token interpreter that executed the program. There was a fourth component, a “binder,” that scanned the tokenized program after you entered the “run” command, and established (and checked) those syntactic connections that spanned multiple lines. The binder had very little to do, and its execution time was typically imperceptible. Source-code debugging fell out of this design: any line being executed by the interpreter can at the same time be output as Pascal source by the backward translator. During debugging the system could appear to execute at the source level, stop on lines with breakpoints, and evaluate source-level “watch” expressions.

The Lesson

The result of this design was the illusion of executing Pascal source language, but at the speeds of typical BASIC programs. In fact, maintaining the illusion of a single program representation became the principal user-interface design goal. It is this illusion of always dealing with your program at the source-code level that resolves the build/run dissonance and that obviates the need for a separate debugger.

The design was successful and next found itself inside Macintosh Pascal in 1984. But the resolution of the dissonance wasn’t complete. Instant Pascal was a trainer, not a construction tool. As compiler writers know, you don’t have a real production tool until you can build the tool using itself, and this could not be done.