KIM-5 Resident Assembler/Editor

On this page:


The KIM-5 Resident Assembler/Editor is a 6502 version of the MOS Technology Cross Assembler. See the pages on the MOS Technology/Commodore assemblers on pagetable.com

The Resident Assembler was written by Michael Corder (of MOS contractor COMPAS Microsystems) by hand-assembling the Cross-Assembler FORTRAN code to native 6502 assembly.
Consequently, both assemblers were compatible in that they understood the same source format, with the same math features and the same directives and options. That way, they defined the basic format supported by all future Commodore assemblers. This means that the Resident Assembler took uppercase ASCII source files.

John Feagans on the origin of the KIM-5 Resident Assembler/Editor:
As a grad student at Iowa State University, Ames, I had access to all the development of these KIM boards as the local contractor for MOS was Compass Microsystems. The original 6502 assembler was written in Fortran and available on Tymshare. First Michael Corder (aka The Cordless Electric Programmer) hand compiled the Fortran to 6502 assembler. Even the Fortran line numbers were used as labels. This became the basis of the MDT 650, an ICE for 6502, and the KIM assembler. Compass developed another product called the MiniMac–a 6502 development system on a plugin for a DEC PDP-11. I took Corders 6502 assembler and hand translated line by line from 6502 assembler to PDP-11 assembly. When I joined Commodore I ported the assembler one more time to become the PET assembler and later C64 assembler.

In 1977, Commodore announced the Resident Assembler/Editor for the KIM-1, which shipped in the form of the KIM-5 ROM board with three 6540 ROM chips (6 KB total) containing the assembler and a simple editor.
The manuals (see below) from 1977 do not mention the .DBYTE, .PAGE and .SKIP directives. In the source (see below) they seem to be recognized and lead to an error.
The assembler could read source from cassette tape or paper tape, but it could not write OBJ files; instead, it would write the binary to RAM.
If the source was too big to be placed in memory, the assembler could read source files from tape until the .END directive was encountered.



All described in the two manuals that I found:

MOS KIM Assembler Manual Preliminary (KIM-5)
MOS KIM Text Editor User Manual (KIM-5)


The KIM-5 Resident Assembler/Editor ROMs
Many years I searched on the internet on fora, websites and friends in the retro world, it did not lead to a dump of the KIM-5 ROMs. It was even doubted the KIM-5 with Assembler/Editor was ever sold, despite the adverts in magazines of that period.

A couple of years ago I saw a listing on ebay.de of a.o. a KIM-5 and a KIM-3B board. I was too late, could not contact the seller or buyer, but I knew the KIM-5 did exist!
A year later Stefan Hamann approached me to ask for information on KIM-1 material he bought from ebay. He was the buyer!
Stefan was so nice to lent me the KIM-5 (and KIM-3B) and the EPROMs he obtained. I have finally a KIM-5 in my hands with ROMs!
The KIM-5 Resident Assembler/Editor is placed in three 2K ROMs of type MOS 6540, and the KIM-5 board configured to show these in memory at E000-E7FF.

With the excellent Backbit Pro Chip Tester I managed to dump the 6540-007, -008, and 009 ROMs. 6540 are strange ROMs, see below. To my surprise the ICs were in excellent condition.
In the other EPROMs (2x 4K 2532) I found a copy of the KIM-5 Resident Assembler/Editor ROMs, nearly identical to the 6540’s. So the dumps are reliable.

ROM dump archives

This archive has the ROM dumps of the KIM-5 Resident Assembler/Editor for KIM-1 Mos Technology Commodore:

  • Dumps of original KIM-5 2K ROMs
    • 6540-007 E000 – E7FF
    • 6540-008 E800 – EFFF
    • 6540-009 F000 – F000
  • Combined to one binary
    (suitable for KIM-1 Simulator 1.5.1 or KIM-1 with ROM/RAM at E000-F7FF

    • kim5.bin E000-F7FF
  • EPROM dump (4K ROMs) (has valid KIM-1 Reset/NMI/IRQ vectors at high memory)
    Small changes like jmp to tape dump routine in the ROM (see sources)
    • KIM E000
    • KIM F000
  • Combined to one binary
    • kim e000-ffff

With the binaries dumped I have

  • loaded in the KIM-1 Simulator (version V1.5.0. with RAM at E000-F7FF added) and started the Editor. See the screenshots below (in which I did not configure the symbol table as instructed in the manual!).
  • disassembled and recreate assembler source which assembles to identical binary and documented as much as possible with the assembler sources on pagetable (PET, AIM 65)

Source of KIM-5 Resident Assembler/Editor
Recreated source of KIM-5 Resident Assembler/Editor with the aid of TASM32, result is binary identical with the ROM dumps.
Tables, data, jump tables, all recreated. A lot is commented, the editor part needs some attention. Assembles fine.
Eduardo Casino helped me to find the last location dependent statements, and now the program runs at other locations like $9000 after adjusting the .org directive and reassembly.
Eduardo Casino created a CC65 version of the source: Recreated source in CC65 Assembler format of KIM-5 Resident Assembler/Editor

Symbol table at $3000

Resident Assembler/Editor at 9000-A7FF


Assembling branch instructions
While working with the assembler Eduardo found weird behaviour by the assembler of the code generated.
Backward branches are done in the usual way. Forward branches generate an extra NOP instruction.
It is not doing any damage, it just wastes space and execution time.

See the next screenshots.


More info and test run at the pages of Eduardo Casino

Difference in time count between R6532 and G65SC32

There is a subtle difference between the NMOS 6532 and the CMOS G65SC32 datasheet regarding the timer of 1 in elapsed time.

It is in the paragraph starting at ‘Once the time has counted down to 00000000, an interrupt will occur ….’
On the 6532 that takes 27T (T is the clock tick), on the G65SC32 28T.
That makes in the example the total elapsed time 443T on the 6532 and 444T on the G65SC32.

Look at these pages about the timer from the datasheets of the R6532 and 6G5SC32 (see below and here)

R6532 datasheet page 5


R6532 datasheet page 6


G65SC32 datasheet page 4

G65SC32 datasheet page 5

Rockwell R6532
GTE G65SC32

Different versions of KB9 Microsoft Basic for KIM-1?

MOS Technology 6502, 9 DIGIT BASIC by Microsoft, Copyright 1977. often nicknamed KB9, is an early version of Microsoft Basic adapted for the KIM-1. With 9 digit precision and the Microsoft version of Basic a very usable high-level language for a KIM-1 with 16K extra RAM and a videoterminal or teletype.
I bought my version in 1979, serial number 2167. Tape ID #01, 2000-4260. Start 4067.
It is a version that works around the missing ROR instruction on early 6502 CPU’s.
All versions of KB9 on the internet are from the cassette dump I made in 2006, including the brilliant source version on pagetable. Still have a lot of fun with it as well as all the KIM clone users.
I found a photo of MOS TECH 9 DIGIT BASIC FOR KIM, COPYRIGHT BY MICROSOFT 1977 2000-437D ID #101 ST. 4065 S/N 217 cassette of a much lower serial number.
What is interesting is the higher End address, 437D versus 4260.
Alas no dump of this cassette is known, so this stays a mystery. as is the illegal tape ID 101.

My MSBasic for the KIM-1 cassette

Another MOS TECH BASIC for KIM-1

RNB VAK-1 photos

Thanks to Eric Dennison I can show photos of the RNB Enterprises VAK-1 motherboard.

The large motherboard and the huge case with homebuilt 16K static RAM memory card are representative for the KIM-1 systems then!

Photo by Eric Dennison

Photo by Eric Dennison

Sorbus internals

The Sorbus concept looks simple. A 6502 CPU, a RP2040 controlling it and a backplane.
It delivers a 6502 system running at a clock speed of about 1 MHz.

On the software side there is much happening. Here some notes written by SvOlli

Meta mode
Pressing CTRL ] brings up the socalled meta mode.

Notes On Implementation in RP2040 Multicore Architecture

Core 0 runs the console and handles user interaction. Core 1 drives the bus for the CPU implementing the system. To have a rather efficient (fast as in ~1MHz) system, core 1 really has to come up with some tricks. So, every “event” aspect, such as timers, watchdog and other things will be run by an event queue. This means on every clock cycle there is a check if something was scheduled for this specific clock cycle. Again due to performance, only one event will happen during that clock cycle. If two events are scheduled for the same clock cycle, the second one scheduled will be delay by one clock cycle (and again until there is a free slot). The size of the queue is 32 event. This should be sufficiant, as there are not much things that could add to the event queue, and in most cases, a new event from the same source replaces the old one.

However: again due to performance the queue is not thread safe! So only core 1 is allowed to interact with it.

Core 0 on the other hand is allowed to do two things on the hardware side:

pull the RDY line low (to stop the CPU) and back high (to let the CPU continue)
pull the RESET line to low (but not back to high again), this may be only done if the RDY line is high, or immediately pulled high after the reset line was pulled low (immediately = in the next code line!)
If core 1 should want to use the RDY line for some reason, this should be implemented using “queue_uart_write” with characters > 0xFF. For performance/latency reasons it also does pull RDY low itself as well.

CPU Detection Routine

The Sorbus Computer can run any kind of 6502 variant that shares the same pinout. The small test and learn environment “Monitor Command Prompt” or MCP for short (pun very intended) can be used to learn all the details about each CPU up to a certain degree. (Not all pins are connected due to a limit amount of 30 GPIO pins of the RP2040.)

However, it is interesting to know which CPU the system is running on. The “Native Core” is the one with the most features, but does uses opcodes and features that are not available or buggy on an (old) NMOS 6502. This means that a 65C02 or any other CMOS variant is required. So, it should be a good idea to detect that CPU and print an error message that the system won’t work with one installed.

Also, there is another point where a CPU detection is very handy. If you search for cheap 65C02 processors, you typically find offerings on ebay or AliExpress for WDC W65C02S processors. However, none of those are original ones, but all of those are pulled out of machines, and then get relabeled. (At least the ones I’ve seen so far.) For this project using those would not be that bad, if they would not throw in NMOS 6502s in the mix as well. Those, as explained above, don’t fit the requirements.
Heree the source of the routine.

Read the rest of the notes on SvOlii’s github page.

Part 5 More software for the Sorbus

In part 4 I showed how to load and run Wozmon and MCP programs on the Sorbus.
Those cores could be loaded with the basic ‘Press BOOTSEL at powerup and drop an UF2 file on the disk’ procedure.

  • Part 6 talks about the Sorbus internals.
  • Here I show how to load the more complex UF2 files SvOlli provides. It is not a simple ‘drop a file’.

    This is what I did (on Windows).

    1. Unpack the cores of the release in a folder, e.g. sorbus/cores
    2. Get a working picotool.
      Some searching on the web brought me to this website where I found a command line Picotool for Windows
      1. Download pictool.exe from the website
      2. You will need to download and run zadig: https://zadig.akeo.ie/
      3. Set pico in bootmode, run zadig
      4. You will want to select “RP2 Boot (Interface 1)” from the dropdown, and install the “WinUSB” driver.
      5. Start a command prompt (‘terminal’ and type
        picotool load -v -x your-build-file.uf2

    I did this with sorbus-computer-native_alpha_picotool.uf2 and got a nice menu driven interface to various programs as shown below.
    Note that option 0 brings up CP/M-65 (with my Pascal-M!). There is also OSI Basic, Taliforth, Instant Assembler TIM and programs developed by SvOlli.


    post

    Part 4 Sorbus runs Wozmon, Apple 1 Basic, MCP

    The first test run of the Sorbus computer can be done with two simple images: Wozmon with Apple 1 Basic and the MCP program
    Part 5 will show more Sorbus sofware
    For this test I used a Rockwell R65C02P4, and jumpered at +5v at the Sorbus Junior.

    The releases of the github of SvOlli provide the uf2 files, cores as SvOlli calls them.

    Insert the 6502 in the IC socket and press BOOTSEL button, connect power via the PC and you see a new disk in the file system.

    – Drop sorbus-computer-apple1.uf2 on the disk
    – start a terminal emulator (I use Teraterm on Windows, Minicom on Linux will work fine too)
    – select the serial port that just appeared
    – any baudrate will do

    and you have the Apple 1 Wozmon and Apple 1 Basic (and Krusader) running.

    MCP

    According to SvOlli MPC, Monitor Command Prompt, is not an environment to act as a standard computer. It is intended as a system to take a look at the CPU which is as deep as possible without emulating it. So dumping of registers for example is not possible. (In theory it is using a trick, but this needs to be implemented, yet.)
    You can see what the CPU does during every single clock cycle with MCP.

    There is an extensive description By SvOlli with examples of what MCP is capable of.

    Insert the 6502 in the IC socket and press BOOTSEL button, connect power via the PC and you see a new disk in the file system.

    – Drop sorbus-computer-mcp.uf2 on the disk
    – start a terminal emulator (I use Teraterm on Windows, Minicom on Linux will work fine too)
    – select the serial port that just appeared
    – any baudrate will do

    The command ‘cold debug’ does a very good job of determining which 65XX(X) CPU is inserted!

    post

    Sorbus computer part 3: the hardware

    The hardware of the Sorbus computers could not be simpler. Designed with care to be as flexible as possible, fully programmable in behaviour, with a small footprint and at very low cost.
    Two components: a 6502 CPU and the ‘purple’ RP2040 board.
    Part 4 is about software, like Wozmon.
    The design is open source hard- and software. Have a look at the Sorbus github page for the details. All information here is based upon this.

    The goal of the Sorbus system is to play with the 6502 as simple and affordable as possible. It can run many serial terminal based 6502 programs, such as the Apple 1 Wozmon monitor, or the TIM monitor with a system clock over 1 MHz or special programs to study the behaviour of the 6502, step by step at very low clock rates (with a 65C02, the CMOS variant is a static design)

    The Sorbus computer is 6502 based, including the 65816. The RP2040 serves as fully programmable peripheral for clock, reset, NMI/IRQ, RAM, ROM, serial I/O.

    • A 65XCPU, the CMOS variants will work best, since they are static and can run at very low clock speeds
    • A Raspberry Pi Pico RP2040, on the ‘purple’ board, which you can buy e.g Chinese sites, exposing 30 GPIOs, more than the official Pico.
    • A backplane with the 6502 bus, all relevant signals under control of the RP2040.

    The 30 GPIOs of RP2040 on the ‘purple’ board of the available make it possible to control any 6502 CPU.

    SvOlli has designed two systems, identical in behaviour, around the Sorbus concept: the larger Sorbus system with a backplane with 6 slots with a 6502 CPU card and a RP2040 card. And the Sorbus Junior, with a backplane with 4 slots and CPU and RP2040 on the same PCB.

    Sorbus Junior

    A backplane, 32 pin connector

    The RP2040 has complete control with its 30 GPIOs of the 6502, all address and datalines (24), CLK, Reset, NMI, IRQ, RDY, R/W (6), total 30. GND and VCC add up to 32, the number of pins on a backplane slot.
    Note that is a very basic and limited backplane. Notable missing signals are SO, Phi1. And for the WDC65C02 BE, VPB and MLB are missing. In practice most expansions can be made with this backplane, like I/O. How this conflicts with the RP2040 in control needs to be seen.


    5 V tolerance
    A 6502 CPU require 5V for power and all signals are at 0 or 5V level. Only the WDC65C02 runs at 3.V or 5V.
    The GPIO’s of the RP2040 are officially not 5V tolerant. Only if power is fed into the GPIO part of the Pico, it can tolerate 5V it seems.

    Since the whole system is driven by one power supply, coming of the USB connector of the RP2040, it might be safe, but no guarantee. SvOlii has not seen problems with this in his systems.
    When you have external devices feeding into the Sorbus, and those are powered on and the Sorbus off, you are in trouble.

    There are several jumpers (J5 on the Sorbus Junior, J2 on the Sorbus RP2040 Chipset board) available to feed the 6502 with +5V (called VBUS on the RP2040, directly connected to the USB connector.

    6502 variants

    The Sorbus accepts many 65X02 variants without jumpers. Not used outputs are left unconnected, unused inputs (SO, Phi1) are tight high with a 3k3 resistor.

    Pinout differences: BE is available on the WDC65C02, not connected on all other. Has a pullup 3k3 to enable the BUS Enable.
    The 6502 has two GND (Vss) connections on pin 1 and 21. On the WDC6502 pin 1 is the VPB output signal and is left unconnected on the Sorbus.

    post

    Sorbus computer (part 2)

    Soldering the PCBs

    I got from Sven PCBs for the Sorbus and the Sorbus Junior. It took an afternoon to solder all parts, the bus connectors took most of the time (10 x 40 pins!).

    In part 1 the Sorbus computer concept was introduced, designed by SvOlli.
    Part 3 is about taking a look at the hardware.

    I decided I wanted to be able to exchange all parts, you never know what might happen during the experiments.

    To be able to exchange the CPU’s the IC socket is replaced with a ZIF socket. Sven is working on supporting many 6502 variants, and that will be more fun with a ZIF socket.
    The PCBs are not designed for that, so it is a bit tight. On the Junior one resistor R1 is moved to the other side of the PCB. On the Sorbus it fits!

    The RP2040 is placed in a pin bus connector, so it can be replaced.
    All these additions increase the height of the PCBs. But it fits.

    post

    The Sorbus computers

    A new development! A minimal 65(C)02 system, called Sorbus designed by Sven Oliver Moll (SvOlli).
    Thank you Sven for this!

    The hardware of the Sorbus computers could not be simpler. Designed with care to be as flexible as possible, fully programmable in behaviour, with a small footprint and at very low cost.
    Two components: a 6502 CPU and the ‘purple’ RP20240 board.

    The design is open source hard- and software. Have a look at the Sorbus github page for the details. All information here is based upon this.

    The goal of the Sorbus system is to play with the 6502 as simple and affordable as possible. It can run many serial terminal based 6502 programs, such as the Apple 1 Wozmon monitor, or the TIM monitor with a system clock over 1 MHz or special programs to study the behaviour of the 6502, step by step at very low clock rates (with a 65C02, the CMOS variant is a static design)

    The Sorbus computer is 6502 based, including the 65816. The RP2040 serves as fully programmable peripheral for clock, reset, NMI/IRQ, RAM, ROM, serial I/O.