This is hobbyist style build based on the Motorola MEK6800D2 from about 1979.
When i collected the MicroVAX I from the seller, Jan, she showed me this unusual machine. Her late husband, Andrew had built the machine back in about 1979. It obviously became an enduring treasure. The family generously donated this machine to me for which i am very grateful. It gives me a real kick to restore a machine that has been important to someone.
The case is a little agricultural, but it has nobly protected its innards for 45 years. The cards and backplane are in very good condition.
The machine carries the moniker of “Deep Thought” as a nod, no doubt, to “The Hitchhiker’s Guide to the Galaxy”. The name is hardly unusual but it is the only one i have so that is what i will call it.
I expect that this machine was built, modified, and expanded over several years. Andrew would have started with the Motorola Evaluation Kit II (MEK6800D2). This kit was for evaluation of the 6800 processor ie it is a little like an MCS85 System Design Kit for the Intel 8085 processor. These types of kits could also be used in teaching labs or by hobbyists, although machines like the Heathkit ET-3400 provided a more polished alternative.
The kit included a single board computer based on the 6800 processor. It included a 1kB ROM with the JBUG system monitor, 384 bytes of RAM, a serial port and a cassette port.
The MEK6800D2 is a little unusual in that Motorola provided many off the shelf enhancement options. Andrew added a video/keyboard, I/O, and 32k Memory cards. An ROM monitor, CRTBUG, for video/keyboard card has also been added.
Along the way it seems that some older functions have been removed. It looks like there were once some connections to a parallel port, for example.
A folder with a few notes has survived but no cassettes have surfaced (as yet).
The MEK6800D2 kit is well documented in manuals available online, but the additional cards are more unusual and so far i have not found a lot of information on them – just enough to get started.
I aim to get this machine running from the installed ROM monitors. Ideally i would like to be able to load some sample programs via the serial interface and save and load from cassette. I have a 6800 cross-assembler that runs under CP/M but i’d obviously prefer a cross-compiler in C or Pascal.
I would like to retain the personality of the build, but some changes are inevitable – particularly to make the unit safe and robust.
The lid was already begging to be removed and curiosity demanded it.
The unit contains a MEK6800AB backplane with:
MEK6800D2 Processor Card
MEK68 I/O Card
MEK68MM32 32kB Memory Card
MEK68R2 Video card
There are several connections to the cards including coaxes for the cassette interface and the video output, and a DIP connector for the RS232 line.
The front panel card (must get a photo) connects to the processor card by a bright red ribbon cable. This was disconnected and that be be deliberate.
The bus interface on the processor uses an edge connector whereas the other cards use a SIL connector. The former is consistent with Motorla EXORciser Bus and the latter is referred to as the Motorola Kit Expansion Products (MOKEP) interface.
The processor card includes the 6800 processor, which seems to be suffering some corrosion – a common occurence with ICs using silver plate rather than tin.
It also has two different Parallel Interface adapters: an MC6821 and an older MC6820 (in a ceramic package). There are two ROMs. One is clearly the JBUG ROM. The other is presumably the CRTBUG ROM. The third ROM socket is unoccupied. There is a 128B RAM which is used by the JBUG ROM program. The 4x 128B RAM sockets in the lower left have been filled with an Australian produced RAM daughter-board that provides a massive 2kB!
There are clearly some mods, one of which i expect is to select between the two onboard monitor programs using a front panel switch. A front panel reset switch is wired directly to the S1 footprint.
The two upper edge connectors are for the PIAs. One of these is used to connect the keypad/display board. The other is user defined – it appears to be used for a small I/O board (get photo) – two relays and drivers, i think.
The keypad/display card connects to the processor card using a ribbon cable. It also has some circuitry for the cassette interface.
The I/O Card is not fully populated. There are two Asynchronous Serial Interface Adapters (ACIA); one for the cassette interface and one for an RS232 port. There is one Parallel Interface Adpater (PIA) and provision for one more. I/O connections are made via loathesome 16 and 24 pin DIL cable connectors. There is a switch to select 300 or 1200 baud on the cassette interface and two RCA connectors for same. There is a manual available for this card.
The video card uses the popular MC6845 video controller. It has 2kB of RAM so should support 80 columns by 24 lines. I have not located a manual for this card. Hopefully it will just work with the CRTBUG monitor and the keyboard otherwise i’ll have some reverse engineering to do.
The RAM card is populated with 32kB of dynamic memory. Again, i haven’t been able to find a manual for this but i assume that it is located at 0000 and overlaps with the processor card RAM and option ROM. Perhaps some of the mods on the processor card take care of this.
The ASCII keyboard uses a mask programmed Intel 8048 microcontroller with what is likely to be a custom version of the General Instrument AY-5-2600 Keyboard Encoder.
The MEK600D2 has a standard configuration as supplied by Motorola. In this configuration it runs the JBUG monitor from a mask programmed ROM.
The default memory map is as follows:
The memory space is not fully decoded. The main decoder divides the 64k space into 8x 8k blocks. The JBUG ROM, for example is mirrored 7 times – which is probably how it is able to boot in the first place as reset causes execution to start at the top of memory.
The I/O appears even more curious with the address ranges of devices overlapping ie it would be possible to enable multiple devices at the same time using undocumented addresses. eg the One PIA is active when A2=1, the second PIA is active with A5=1, and the ACIA is active with A3=1.
The processor board has been modified with a 2k RAM board, so the RAM occupies the space from 0000h to 07FFh. Or at least that would be the case if other modifications had not been made.
The baseline board has a separate 128B RAM block set aside at A000h for the JBUG stack. This also, occupies a full 8k of memory space.
It seems that the MEK6800D2 expansion with external MOKEP boards was not entirely thought through by the time the D2 was released.
The first example is the 32kB expansion card which requires a contiguous 32k memory block which does not exist in the baseline design. The area from 2000h to 5FFFh was unused (the decode lines (2/3 and 4/5) go to the EXORciser interface.
The remaining area from 0000h to 7FFFh is reclaimed by disabling the expansion PROM at U12, and then re-allocating the RAM at 0000h to the area used for the dedicated JBUG stack RAM at A000h. It is not clear that the original stack RAM has been disabled. I will check.
The card has both the JBUG and CRT ROMs installed. The socket U10 has been modified so that both ROMs are enabled by PROM0_L at E000H. A switch is used to enable one ROM at a time.
There seems to be no device at C000h. It may be possible to move the ROM (U12) that was at 6000h to this location. This ROM has a lot of configuration options so it may be possible to configure the slot for a 2716 EPROM or even a 2732 EPROM. This would be very handy for routines to use the serial ports.
Address Range
Device
Card
E400h-FFFFh
JBUG/CRTBUG (mirror)
MEK6800D2
E000h-E400h
JBUG/CRTBUG
MEK6800D2
C000h-DFFFh
Unused – use as ROM?
MEK6800D2
A800h-BFFFh
2kB Stack RAM (mirror)
MEK6800D2
A000h-A7FFh
2kB Stack RAM
MEK6800D2
8000h-9FFFh
I/O Space
MEK6800D2 MEK68R2 MEK68IO
0000h-7FFFh
32kB RAM
MEK68MM
The I/O space presents some issues as it is shared by three cards.
Helpfully, there is an application note that discusses possible modifications to accommodate various MOKEP cards. It highlights that the VMA signal can be modified such that it will suppress MEK6800D2 devices under the control of a new backplane signal called ACT (active). This is also described in the MEK68R2 manual.
ACT can be generated by other cards to break into the MEK6800D2 memory space. eg an external card can assert ACT to push a device into the 8000h-9FFFh I/O space of the MEK6800D2.
ACT is open collector so that it can be used by multiple devices. The ACT signal was introduced by modification of the processor board:
The effect of this signal is primarily to control the flow of data ie to ensure that the MEK6800D2 data transceivers allow data to flow from the backplane data bus to the card databus when an external device is read.
Condition
Transceiver Direction
R/W_L
MEK6800D2 decoder output eg I/O_L
internal device is being read
out or off
1
0
internal device is being written
out or off
0
0
external device is being read
in
1
1
external device is being written
out
0
1
This is really only problematic for the I/O space at 8000h to 9FFFh because this 8k space is shared with the MEK68IO I/O Card and the MEK68R2 CRT Card.
The ACT signal is certainly generated by the CRT card but does not seem to be generated by the I/O Card. To add to the intrigue, the I/O Card decoding relies on a signal, I/O1, which is, in this system, generated by the CRT Card. And there’s more; the ACT signal generation for the I/O Card appears to be handled by the CRT Card. Lordy, what a horses arse!
The CRT Card also generates I/O2 which is not currently used on this system but could be if another card (eg a bespoke I/O card) was added.
ACT should be asserted when:
The I/O card devices are accessed
The CRT card devices are accessed
The CRT Card memory space is accessed
The I/O2 range is accessed
If the I/O range 8000h to 9FFFh is selected then ACT is asserted except if the address is within the I/O1 range (8000h to 807F) and A6=0 ie 8000h to 803F. This is where the MEK6800D2 I/O devices are located. The I/O card must be configured so that the addresses are outside of this range.
The I/O Card can be configured for 4 different sets of addresses:
The card in this system is configured for option 2 but there is a further modification to A6 which removes an inversion. This adds 40h to each of the device addresses except the IEEE interface. This takes the devices into the range for which ACT is asserted.
The I/O Card has not been loaded with the IEEE interface. If it was then it would not work properly because its modified address would have A6=0.
The power supply looked like it had suffered a little. The cheese-grater enclosure was neither robust nor dust proof.
It was fairly easy to remove the case. I’m all for keeping things original, but mains power needs to be taken seriously. Inside i found an off the shelf Motorola open frame linear power supply.
It is the perfect companion for the computer so i set about cleaning it up. There were no obvious issues so i powered it up using an autotransformer.
I brought it up slowly without load and it survived the experience. The voltages were pretty good. I added a nominal load and it seemed to hold up fine.
The power supply has two designated connection points for mains fans. One was used for a fan attached to the cheese-grater case, and the other connects to a fan in the computer case. This is not great because it involves a live plug (ie live pins), and the computer case is not clearly earthed.
The power supply does claim short circuit protection, but the chassis wiring does not include a fuse. The mains cable has become quite stiff with the passing years; i will replace it.
The DC cabling is re-used 10A mains cable. It does not make use of the sense inputs on the power supply.
I think it is probably worth starting afresh on the power supply chassis.
I had already cleaned the power supply and tested with a small load.
The enclosure really needs some work and the cards would be hard to access inside the case, so decided to pull all the connectors and cabling out. I gave it all a clean and set it up on the bench.
In preparation for power on, i applied de-oxit to all of the socketed ICs and reseated them.
I started with the backplane and power supply. I checked all the power wiring several times, fearing that somehow i would get the voltages muddled. Then i powered up and nothing bad happened with the backplane alone.
Then i added the processor card and checked voltages. Still ok, so i added the keypad/display card. The 5V at this card was starting to get a little low. I think the regulation would be improved markedly if the power supply sense lines were used.
On power up nothing was displayed. I tried the reset. The switch feels terrible but is just working. Still no display. Then i toggled the CRTBUG/JBUG switch and reset again. This go the dash (-) display that was expected. Splendid news indeed.
The requirement for a manual reset at power on seems a little primitive.
I did a crash course on JBUG and was able to enter some commands and edit some memory locations. There was no memory at 0000H, but there was 2kB of memory at A000H. That’s consistent with the mods.
Next i added the 32kB memory card which also seemed to work fine.
Next i added the Video card and connected a monochrome video monitor. This required toggling the CRTBUG/JBUG switch and hitting the reset again. After some adjustment of the horizontal sync on the monitor i got a CRTBUG 1.0 sign on message. This was a lot of progress in a short time.
I was able to start up either monitor using the switch provided for that purpose. I assume it is messing with the chip enables on the two ROMS.
Then i added the ASCII Keyboard and progress ground to a halt. The only key that seemed to work was the space bar. I added the I/O card in the just to confirm it made no difference. It did make no difference.
When i looked closer at the keyboard i noticed that there were no key switches soldered in. I removed the screws and quickly found that the board is a capacitive type similar to that used on the Kaypro II and the Compaq Portable.
These keyboard use foam pads with a conductive layer on plastic. Typically, both the foam and the conductive layer deteriorate and need to be replaced. In this case only a few pads had retained their conductive layer – one of them is the space key.
Replacement is laborious and made worse by their complex shape. This is a job that can wait until after i have confirmed that the computer itself is working well.
Until then, i can use a PS/2 keyboard with an adapter to make it appear as an ASCII keyboard. I’ve done this before with a Microlog Little Video Board. Once the pinout was sorted (with some buzzing followed by guesswork) the keyboard was good and i could enter commands using the CRTBUG monitor.
The CRTBUG monitor is a lot easier to use than JBUG so i could do rough write/read tests on the RAM.
I found that the Zenith monitor struggled with the horizontal sync, but the video seems fine on a modern video monitor.
I should see if i can jump to CRTBUG from JBUG.
There are cassette ports on both the processor card and the I/O card. JBUG is made for operation with just the MEK6800D2 so it would use the interface on the processor card. I was not sure what the CRTBUG would do, but when i “punched” to tape it definitely used the one on the processor card.
A while after i had picked up Deep Thought, i was contacted by the donor to say that she had found some documentation. The hardware manuals are particularly important. I will eventually scan anything that is not already on the web.
This was a hobbyist style build by a young man so it is naturally a little rough around the edges. As changes were made holes were drilled and lights and switches were added and sometimes removed. The panels have some labels from a classic Dymo label machine. All of this adds to the character of the machine. I’d like to keep as much of that character as i can.
There are issues, though. Of course some of these are more important than others. They fall into four categories:
Safety
Functionality
Reliability / Maintainability
Cosmetic
Safety Issues
Resolution
The power supply enclosure is too flimsy.
Complete rebuild using 1.5mm aluminium sheet. Use similar construction to computer unit.
The wiring is not fused.
Add fuse on 240V and on each DC rail consistent with DC wiring.
The fan in the computer enclosure runs from 240V and (a) the plug has live pins and (b) the chassis is not earthed.
Replace 240V fan with 12V fan.
Several aluminium sheets have sharp edges where they have been cut or drilled.
De-bur.
Tired power lead.
Replace with IEC cord and filtered entry.
The functionality issues are generally minor:
Functional Issues
Resolution
The video and tape connectors are on the front of the unit and the video connection is not the usual RCA.
Add connectors on rear.
Cassette remote control connector missing.
Add to front and rear of unit.
The parallel ports on the processor card and the I/O card are not accessible outside the enclosure (although the processor card parallel was exposed in an earlier state).
Add 50 pin ribbon cable panel mounted connectors for each port.
The I/O card supports two parallel ports but only one parallel port MC6821 IC is fitted.
Add the chip.
The power supply provides sense inputs for the 5V supply but they are not currently used.
Add feedback lines from the computer terminal block. This will require a new power connector.
The keyboard does not work because the pads have deteriorated.
Make new pads and fit. The pads are an unusual squarish shape, so this will be time-consuming.
Toggle switches seized.
Replace.
No power light.
Add power lights to power unit and computer unit.
Second cassette control unit is not used. I think this may have been for use with a different ROM than the ones installed. It seems to match SWTBUG but it is not clear that this would have run with the exeisting hardware configuration.
Park the board.
Third ROM socket not used but could be.
It should be possible to configure the socket for a 2716 (2k) or 2732 (4k). This would allow some additional firmware space if required. The ROM would be located at C000H.
Reliability and Maintainability Issues
Resolution
DC wiring has been done with mains flex. Colour coding is not great.
Re-do with appropriate cable.
Several soldered connectors where IDC could be used.
Replace.
Several wires soldered directly to processor board.
Add connectors to prototype are and wire via those connectors. Use 16 pin 0.3″ socket IDC similar to those used elsewhere.
16 pin 0.3″ dip connectors are soldered and prone to breaking.
Replace with IDC where possible.
Dry joints on several connectors.
Reflow solder.
Fragile keyboard cord.
Fix keyboard entry. Wrap ribbon cable in loom tube.
Cosmetic Issues
Resolution
Aluminium finish oxidised and scratched.
Work with scotchbrite.
Front panel cutouts are too rough.
Square off.
Missing and corroded fasteners.
Replace. Use countersunk screws for neatness.
Rear and right panels have large unused holes.
Replace panels.
Lid not properly fixed and too light.
Replace with 5mm perspex – strong and allows the interior to be enjoyed.
Processor board wiring. The mods are a little “in your face”.
