MITS Altair 680


This page last updated JUne 25 2023. To see other restored microcomputers, check my examples Web page. For my own work and discussion about why to restore these old computers, check my vintage computer restoration home page. Other pages on my Web site are linked from there. My contact information is at the end of this Web page. - edited by Herb Johnson.

Introduction

[MITS Altair 680] This Web page discusses the MITS Altair 680, a computer product line first produced by MITS in late 1975, with a Motorola brand 6800 microprocessor. It's not compatible with the "Altair bus" Altair 8800 which became the first S-100 system. Check that Altair 8800 Web page for a company and product history of MITS. This Web page will discuss the 680, provide some resources, and show discussion from some current owners of their systems. - Herb Johnson

Some general 680 history

Notes from an employee

I discussed the Altair 680 product line in Sept 2011 with a former Pertec employee. Pertec bought both iCOM and MITS, and sold some MITS products rebranded as iCOM. Here's a summary of what he said to me. - Herb

The Altair 680 did not sell well compared to the 8800. It found a niche market as a machine or process controller. After the iCOM acquisiton, the Turnkey model of the 680 (with reduced function front panel) was sold in the ICOM product line. As far as I know the motherboards were the same for both models.

Several MITS products died because Pertec focused on the Business Computer products. Hobbyist, engineering, and manufacturing markets faded accordingly. I'm guessing that the arrival of Phillips NA marked the end of everything "MITS" except the PCC 2000 system.

I was told that 680 BASIC is fast compared to 8080 BASIC. But the speed is of limited use without more RAM and floppy drives. The general market developed to use 8080/Z80 code, and CP/M and accounting software was hungry for RAM. - (end)

the MITS680 is not S-100

While the MITS 680 uses the same 100-pin edge connector as the MITS Altair 8800; it's not S-100 compatible. The 680 bus boards' edge connector is in a different board-edge location than the MITS Altair 8800 boards and other S-100 boards. And, the MITS 680 bus signals are on entirely different pins. Here's a list of MITS 680 bus signals. I had to write it myself, MITS doesn't list them in their system docs. Here' details on the S-100 bus signals.

About the bus connector: My June 2023 inspection of MITS 680b expansion board at deramp.com shows photos of the connectors on the board as "1977 Sullins ESA50DRKH. They look the same as the expansion connector on the 680b main board (which is not visible). The MITS BSM (16K memory) parts list, specifies the same MITS "100 pin edge connector 101864" to add to the expansion board. The MITS 680b manual does NOT specify a connector, it's not included, it comes with the expansion board (no manual at deramp.com).

Web search in 2023 at sullenscorp.com catalog finds variations of this connector but the part number is not in their current catalog. I can piece together the specification. PBT/Phosphor Bronze pins (E), 10 microns gold (S), .125 centers between pins (A); 50/100 pins, dual rows (D), dip solder low profile pins .140" row spacing (RK), .125" clearance (end-mounting) holes (H). (Another Altair 680B photo, shows a Sullins 377? ESA50DRTH: "RK" and "RT" are the same spec in the Sullins catalog.)

Thus the connector itself, appears to be a MITS Altair compatible connector. Refer to my S-100 bus specifications Web page for details of MITS and non-MITS S-100 edge connectors (yes there's a difference).

Martin Eberhard's 680

[MITS Altair 680] [Martin's 680]

A number of people own these systems today and are working on restoring and running them. Martin Eberhard contacted me in Sept 2011 with this account of his 680 work as below. My comments or edits are in []'s. - Herb

"[My] Altair 680b is currently loaded with two 16K RAM boards, and soon to get a universal I/O board (2 parallel, one serial). The serial port on the 680b main board is connected to a cleaned-up [Teletype] ASR33, and boots Basic. I have not yet tried their assembler and editor, but I have original tapes for these, and I suspect they will work perfectly. I am trying to keep this machine as authentic circa 1976-1977 as possible - no newer boards, load from paper tape, etc."

"The 680 is actually a very simple machine and pretty easy to get working. It is cute with its blinking lights, but it is also limited. The front panel only allows you to examine/modify memory - no jumping to an address, no single-step, no seeing where the CPU is running code. Its 6800 CPU runs at only 500 kHz, so Basic programs [when adequate memory is available] run somewhat slowly. But when you're seeing it through the 110 baud interface of the ASR33, the 500 kHz clock rate hardly seems like a limitation :-)"

"My particular machine came with two transformers in the power supply, with their outputs wired in parallel. This looked like somebody's hack to me, so I removed the second transformer. Then I saw a 680 that's coming on the market [at that time.] This one's also hacked, but it has the two-transformer setup, and some of the people commenting [on the sale] have suggested that dual transformers was a power supply upgrade from MITS."

680 board set

Martin Eberhard describes the 680 board set and some of his plans.

"Because it uses a proprietary bus, there are very few boards. As far as I know, this is a complete list of boards for the 680 bus:

* 680 Expander board - gives you three expansion slots. [See comments below.]

* 680b-BSM 16K Static RAM (I own three - [the 4200ACD model RAM chips you sold me] will restore the third one)

* 680b-KCAR Cassette tape interface (I want one of these)

* 680b-PCI Process Control board (relay & opto-isolator board - I want one or two of these!)

* 680b-IOU Universal I/O (2 parallel, 1 serial) (I own 3 of these - willing to trade one for a PCI or KCAR)

[There was also a 680bt system, which has a limited front panel without address and data lights and switches.]

Description of 680 Expander

[The 680 Expander Board] has contacts on the top as well, as though they intended some sort of expansion box on top of the 680b chassis. but as far as I know, no such product was ever offered. I am considering reproducing the expander board because they have become scarce. The machine is very limited without the expander board - [only] 1K RAM [on the motherboard and one Expander slot]. [However,] the expander slot on the 680 main board is not useful for plugging in a 680b board such as a memory board. Although the connector is correct, the board will not fit - the bottom edge of the board will interfere with power supply components on the main board, and the top of the board will interfere with the cabinet.

I have seen an advertisement for the [model] 680bt labeled as an iCom "CP6800", though I have never seen one in real life. I have seen no ads for boards from iCom. I have never seen or heard of a 3rd party board for the 680. (Pertec bought both iCOM and MITS, and sold some MITS products rebranded as iCOM products for a few years.)

During October and into November 2011, Martin designed an expander card for the 680. He discusses it briefly below, as a solution to a problem with memory card errors. - Herb

680 memory design

The real shame of the Altair 680 is MITS's failure to understand the MC6800's 2-phase bus. If designed correctly, the alternate phase (phase 1) gives you a free, transparent DMA channel. I used the MC6800 in my first professional design - the Wyse WY-30. During phase 2, the MC6800 had access to the memory system. During phase 1, the CRT controller (MC6845) had access to the memory system. This way, the MC6800 never saw a wait state, and the CRT was refreshed perfectly. It was pretty neat. Too bad MITS didn't understand this. Had they designed it correctly, they could have designed a disk controller that DMA'd directly into memory without causing any CPU wait states. The cost of designing the basic machine correctly would have been one 8-bit data latch for the front panel - for example, a 74LS374.

680 software, memory test

[MITS Altair 680]

"I totally lucked into the 680 software [I've acquired]. I bought a less-desirable 680bt on eBay - it went cheap because everybody wants blinking lights. But this one came with original MITS paper tapes for Basic, the Assembler/Editor, and the plain Editor. These paper tapes were still sealed in their original plastic bags. The rubber bands that MITS wrapped them in had turned to mush, and the sticky backs of the labels had dried up so the labels fell off. But that's all. I opened the bags and ran these through my ASR33 exactly once each, to create Master Copies. I have made a few 2nd generation copies from these Masters, and this is what I use to boot."

"[To test memory,] I wrote a decent memory test program in 680 Basic :-) it's kind of slow, but thorough. Takes about 3 hours to test 16K. I could have written it in 6800 assembly, and I guess it would be more than 10 times as fast, but Basic seemed more fun. [On the right] is a photo of my 680 with the lid off. It's actually running my memory test, testing the [RAM] chips I got from you."

"I was actually not unhappy that my first memory test took a long time to run. This proved out several things for me: 1) the memory would retain data for a long time; 2) the entire Basic system works flawlessly, 3) the Altair 680 itself seems rock-solid, running continuously for 5 and 6 hours at a time, 4) the motor stop-start circuit in my Teletype works great, waking the thing up in time to print correctly, never missing the first character after a wake-up." - Martin Eberhard

IN Nov 2011, Martin gave this update: "I wrote a decent hex loader that allows me to load code into the 680 at high speed through the 680-UIO serial port, which makes software development so much nicer. I also found a MS-DOS-based 6800 assembler, called A68. This is not a very good program, and even makes some mistakes while assembling, but I have figured out how to make it work for me..."

Memory testing

"And then I wrote a fairly aggressive memory test program for the Altair 680 in assembly language. I got it working for the first time today, and I see some interesting results. When I test the expansion memory board (I have just one in for now), it works fine. But when I try to test the 680's on-board 1K memory, it misbehaves badly - often crashing my program in ugly ways. It turns out that accessing this on-board memory from code on an expansion board causes address errors - the data sometimes goes to the wrong address - sometimes wiping out my test program."

"My plan is actually to make the memory test MORE aggressive, then chase down (with a scope) where the circuit is failing. I have a few candidates: 1) the decoupling caps may be inadequate for a board with no ground plane. 2) speed problem with chips in the address decoder. 3) some kind of address line coupling - I am particularly suspecting noise/misbehavior on A15. My code actually relocates itself (including its own stack) anywhere you want in RAM, so that any memory can be tested. Writing relocatable 6800 code is a tad on the tricky side..."

"The curious thing is that my hex loader program runs in this on-board 1K block, and runs fine. But it runs solely in that memory, only occasionally writing a byte to expansion RAM. not sure the significance, but I'm betting the problem lies with crossing the on-board/off-board boundary often and quickly. Should be fun to debug.. When I am satisfied with my memory test program, I'll post it on your site, if you like. It's been a few decades since I wrote any 6800 assembly language - it's kind of fun." - Martin

By Nov 2011, Martin reported: "I have been chasing that Altair 680b memory bug that my memory test so nicely exposes. The root cause is a design flaw that gates a glitch created by the 4200 RAM chips onto the data bus. I can think of all kinds of re-designs of the Altair board that would fix this, but none is simple and clean. The ultimate problem is that the Altair 680 requires the memory board to drive the data bus through both phases of the MC6800 2-phase clock, whereas Motorola intended peripherals to drive the bus only during phase 2.

During a memory-read cycle, the Altair 680 requires data to be driven onto the bus through both phases to make the front panel LEDs work - they are driven directly by the (unlatched) bus data signals. If the memory board didn't drive the bus during phase-1, the LEDs would not turn all the way off for data bits that are zero.

To make matters worse, the 4200 RAM chips' data-out signals are latched with transparent latches, which just pass data through when open. But the 4200 produces an ugly glitch on its outputs at the beginning of its chip-select pulse. This glitch drives right through the transparent latches, and gets nicely amplified onto the bus by the 74367 drivers. This, in turn, honks on the ground lines, and you can see the glitch on everything, especially the clock.

As I investigated why one of my memory boards works and the others sometimes fail, I came to the conclusion that poor grounding to the expansion boards [from the motherboard] allowed this glitch to invade the clock signal.

Well well.... Yesterday I got my replica 680 Expansion Boards from the PCB fabricator. With my Expander board (with fresh, new 100-pin connectors and fresh, new gold on its edge connector), all of my memory boards work perfectly. You can still see the glitch still on the clock signal, but at less than half the magnitude - low enough that it does not upset any other circuits. I believe that this [confirms the grounding issue].

680 software and binary format

Here's some files of the paper tapes acquired by Martin Eberhard, with his permission. He says:

"Those familiar with the Altair 8800 know that MITS used a propietary binary format for loading software onto the 8800. Unlike the 8800, MITS used a standard hex format for loading software onto the Altair 680 - the Motorola S-Record format. The disadvantage of any hexidecimal format is that the file will be more than twice as large as a binary format (because every byte gets encoded as 2 ASCII characters), and so will take more than twice as long to load. This is no joke when loading a large program like Basic. Basic takes nearly an hour to load via 110 baud Teletype!

"But there are a couple of advantages to using Motorola S-Records: 1) The file on tape is human-readable - you can open an S-Record file with any editor and make sense of the file. 2) if you get a read error while loading a program, you don't need to start over at the beginning - just back the tape up a couple of feet and start reading - the loader will automatically synchronize to the data and continue loading. 3) there are plenty of tools that can create S-Record files, so you can easily develop software for the 680 on other computers." - Martin

[paper tape and laptop] On the left, is a photo of my laptop (sitting on an Altair 8800a) connected to my Ghielmetti high-speed paper tape reader. [Here's the image files:]

680BASIC.S, which is an exact copy of the MITS 680 Basic paper tape, with a comment at the beginning from me.

680ASSEMBLER-EDITOR.S, which is an exact copy of the MITS 680 Assembler/Editor paper tape, again with added comments. But check the bug report below.

680EDITOR.S, which is an exact copy of the MITS 680 Editor tape, once again with my comments.

"It is worth noting that 680 Basic Revision 1.1 (which is what I have sent you) prints out the message "ALTAIR 680 BASIC VERSION 1.1 REV 3.2". Clearly, MITS was a bit loose with the words "version" and "revision."

[BASIC prompt]

"The comments kind of say it all - the tapes were all originally punched with 7 bits and even parity, though the 680's loader (in the ACIA EPROM) ignores parity. The tapes were punched with a few feet of nulls before and after the data. The BASIC tape had a cute human-readable text message punched into the end of the tape that said "END OF FILE 680 BAS." This text message is not reproduced in the Basic S-Record file... the comments also give you the exact text of the adhesive label that MITS put on the paper tapes." - cheers, Martin

In addition, Martin provided his memory test software, as described above:

"Attached is the source code, listing, and S-Record executable for my MTEST4 memory test program. It's a pretty good memory test program, fitting in less than 700 bytes. Post it if you like :-)" [Included are MTEST4.TXT notes about the memory glitch, grounding, and how to run the program. - Herb]

Also, here's Martin's source code, listing, and S-Record executable for his hex loader UIOLOAD3 program. Included are .TXT notes about how to run the program. - Herb]

680 assembler-editor bug

From George Hunt, Jan 2020: Getting my MITS 680 and ADM3A ready to take to [an event] in Feb, I downloaded the ASSMBLER-EDITOR.S from your website [this Web page] to have it available for show/tell. I remembered a bug in this original MITS assembler I found years ago. "EOR A immediate" doesn't assemble correctly: [it should be 88H not 11H]

00001                     NAM        BUG
00002 0000 11 00          EOR A      #0
00003                     END

The problem is the 11h in location 03A7h in the binary, where 88h is correct." - George

Here's George's fix: quote "680ASSEMBLER-EDITOR.S has a bug. It assembles EOR A # as 0x11. The correct opcode is 0x88. All the other instructions/modes assemble correctly. To modify the assembler insert a new record in the 680ASSEMBLER-EDITOR.S just before the last S1 record. Thus:

   ....
   S1051C807C00E2
   S10403A788C9   <--- Insert this line
   S10400F30008
   S9 

George is correct. But here's a fix I and others have done: we patched the faulty record and corrected the checksum, as follows.

On my copy of that tape, the area where 03A7h resides, would be the S-record line starting with "S11303A0". THAT incorrect line is below.

S11303A00009454F5200D411494E43004A4C494E6E

I count seven data bytes in (after the S1 code 13h count and 03A0 address) and see an "11", which George says should be "88". The bytes before that, 454F52, spell "EOR". To patch the record and correct the checksum, I cheated with an assembled file of byte-codes at the correct address. The CORRECTED line is below. - Herb

S11303A00009454F5200D488494E43004A4C494EF7

In June 2022, Mike Douglas said "I checked code generation for the EOR instruction using the original Altair 680 assembler paper tape and found it generates incorrect code for all variants of the EOR instruction (not just EORA #imm). As George suggested, changing $03A7 to $88 (the base opcode for EOR) corrects the problem, and does so for all variants of the instruction. I updated the corresponding S-Record by changing $11 to $88 and updating the checksum ($6E+$11-$88=$F7). I see this matches what you came up with as well. I have added this updated version of the tape on my website, and also on Martin Eberhard’s archive. Thanks for hosting George’s bug report." - Mike Douglas

In Sept 2022, George Hunt provided an assembled list of 6800 opcodes in alphabetic order, assembled by the fixed MITS 680 assembler-editor. He says, it's all good. - Herb

MITS 680 ROM monitor vs 680 assembler

In July 2020 I found a copy of the MITS 680 ROM monitor documents at deramp.com (link below). There were two seperate monitors: one used the Motoroal ACIA (UART) and supported ASCII; one was bit-banged from one of the 680's I/O devices and supported Baudot or five-level TTY codes. There was on that Web site, a text of the ACIA version, which needed a little correction. Here's the MITS 680 assembly for the ACIA monitor and here's the assembled listing.

In Sept 2022, George Hunt reports this feature of the 680 monitor as assembled by the MITS assembler-editor. - Herb

An assembled listing of the 680b ascii monitor is included in the [MITS 680] documentation. If you assemble this code with 680 ASSEMBLER-EDITOR.S you get two 011 errors.

In line 00242 FFE5 BMI NOTERM 2B 19 (0xFFE5+2+0X19=0X10000)
In line 00252 FFF4 BMI NOTERM 2B 0A (0XFFF4+2+0X0A=0x10000)

Since NOTERM is EQUed to 0 in line 11, both BMI targets are beyond the -128 range of the BMIs and are flagged as a range error. BUT since the 6800 CPU address computation seems to do an unsigned 16 bit + signed 8 bit computation, the result in both cases is 0; which is what is desired. So it seems that the listing we see in the documentation wasn't done on the 680ASSEMBLER-EDITOR.S but [the MITS assembler] generates correct code! - George Hunt 9/7/2022

Other 6800 resources

In 2019 and again in early 2022, I corresponded with Mike Lee about his 6800 work with the SmithBug 6800 monitor. SmithBug was produced by Ed Smith and distributed by Software Works Company. Mike Lee worked through his damaged physical archives of his previous work, and extracted out SmithBug with his addition to support Motorola S-records. See my Web page for the resulting codes. A few bugs seem to have crept into SmithBug, particularly in the debugging code! Also on the Web page is MIKBUG from Motorola. - Herb

[Martin's 6800 assembly code is written with some non-Motorola assembler features, based on the cross-assembler available to him. I took some time in Nov 2011, to revive William Colley's 6800 cross assembler A68. It was written in C by William Colley and submitted by him to the old "C User's Group. Here's a web page for my edited version of Colley's A68 cross assembler. It's compiled for 32-bit Windows in MS-DOS mode, using the lcc-32 C cross compiler which is freely available. To use it as a full Windows program, you have to recompile it or "wrap" it in some GUI. To use it as a 16-bit MS-DOS program, you have to recompile it in, for instance, Borland Turbo C 1.5 for MS-DOS. I've done similar work with Colley's A18 cross assembler for the RCA 1802, which you can find at this linked Web page. - Herb Johnson]

Another 6800-based system available at the same time as MITS' Altair 680, was the SWTPC brand 6800. SouthWest Technical Products produced this system, roughly based on Motorola's VersaBus bus but with Molex connectors. Here's my Web page on my SWTPC 6800 system and some work-in-progress from 2010.

I owned for awhile, a Motorola MEK6800 D2 computer. Take a look.

A pair of 680b systems

My friend and local colleague Bill Degnan and his vintagecomputer.net site has many images and manuals of his TWO Altair 680b computers. He has photos of a second Altair 680b at this link. Also search his discussions for posts by Bill and others.

Bill observes the following: "I was trying to determine what the meaning of the serial numbers are. One of my systems has a serial number of "C 11480" the other "E 11952". Wondering what the "C" and "E" stand for ... although I assume one letter represents the kit version, the other assembled. I am also making the guess that all 680 [serial numbers] started with 11, followed by the production order number....All [Intel 8080-based] Altair 8800 computers started with K 22 nnn or A 22 nnn where K = kit and A = assembled."

680 Web links

The virtualaltair.com Web site, a MITS/Pertec/ICOM resource by former PCC employee Tom Sanderson, has a number of advertizing and brochure images which show 680-related products. An apparently auxiliary Web site location has many MITS 680 documents available as PDF's.

Southwest Technical Products or SWTPC, was an early manufacturer of 6800 microcomputers. Michael Holley of swptc.com had a Web page on MITS 680 BASIC by Microsoft. Unfortunately Holley's Web site was not available as of 2019; this is a mirror created in Feb 2020.

The groups.io group Altair Computer Club has email discussions about MITS computer products and related items. They also have a files archive of MITS related programs, documents, source code and so forth. There's a small amount of MITS 680 material, including the contributions by Martin Eberhard provided here.

deramp.com MFE archive has a bunch of Altair 680b manuals and software.


Herb Johnson
New Jersey, USA
here is how to email @ me

Copyright © 2023 Herb Johnson