Unusual 6800 Microprocessor Trainer

I visted the Newbury Radio Rally yesterday with @EdS and @Revaldinho.

I came back with one of these:

It was made by a UK company called Omni Data Products in about 1979. Googling doesn’t find anything at all about this company or it’s products.

On opening it up:

It turns out to be based on the Motorola MEK6800D2 Evaluiation Kit:

The main power supply capacitor has seen better days. It has leaked rather badly, causing one of the tags to detatch:

Some of the electrolyte has spilled onto the main board, destroying a socket and a MC14040 counter IC. After desoldering the socket, the damage to the PCB turned out to be minor:

Rather than risk using the original power supply, I soldered some leads on and tested it on my bench power supply.

It all seems to be in perfect working order.

This is a well known, if somewhat rare, Motorola 6800 evaluation kit. All of the documentation, including schematics, is available online:


The board has based on a MC6800P (with a now almost invisible date code). It
uses a MCM6830AP (SCM44250P) 1Kx8 Masked ROM containing the Motorola JBUG monitor. It has three MCM6810P (128x8) RAM chips factory fitted, and two F6810PC (128x8) RAM chips likely added later.

That’s a total of 640 bytes, which ought to be enough for anybody! (Oh wait, that was 640KB and somewhat later).

I’ve dumped the JBUG ROM using the following sequence:

A002M E0G 00G E3G FFE P

What’s interesting is it doesn’t quite match the versions online (e.g. on the bitsaver’s site):

The top panel is the end of the JBUG ROM from the bitsavers site, the bottom panel is what I have dumped. The manual contains a ROM listing, and it looks like these four bytes are unused.

The current draw on the bench PSU is 1.1 A, and that’s without the third board (with all the banana sockets) being connected. I will replace the capacitor in the power supply, but I’m not completely happy with the idea of powering this from a single MC7805CT regulator.

Anyway, I’m very pleased to have found this. There are some more photos of this being disassembled in a Google Photos Album: MEK6800D2.

I’d be interested to hear from anyone that knows anything about Onmi Data Products, or has any experiences/anicdotes to share of the MEK6800D2 Evaluation Kit.



Very nice! I’m curious as to whether the cassette interface is any good (and still working) - if you have a C15 Computer Cassette available!

This was the first computer I owned. In 1980 the local Motorola office was throwing them (and a bunch of other stuff) away and asked my father if he wanted it, so he brought it home. It was still in the original packaging. We had to build our own power supply for it but didn’t build a case. It was just the boards, sockets, cables and parts so we had to build everything.

I think I only ever wrote two very simple programs for it. But by reading the manual that came with it while waiting in line for an interview for a job that involved working with the 6800 it helped my chances of being selected (the “6800” on the cover was very large).

In 1982 we sold it to buy a US version (60Hz) of the Sinclair ZX81.


Thanks for the comments so far @EdS and @Jecel.

@EdS I do have a tape somewhere, but nothing of significance to try to load/save. It would be nice to find a non-trivial program that I could try to run on this machine.

I’ve added one more photo to the album where the CPU date code of, I think, C27813 is just about visible. I’ll also attach the photo here:

If anyone is skilled at enhancing images, I would be interested to see if that’s correct.

There is also some corrosion vissible in that photo. I do hope the internals of the socket aren’t too manky. This is more electrolyte from the leaking PSU capacitor. I’ll give it a good wash down in IPA.


Yes, I’d agree with C27813 - if it weren’t for the 3 showing how a 3 should look, I might wonder if the 8 were a 3.

I’ve had a go a writing some 6800 code to bit-bang a serial port (using a couple of the PIA pins).

I’ve created a new github repository for this work:

The system clock is 0.6144MHz, which gives bit times of 64, 32 and 16 cycles at 9600, 19200 and 38400 bauds respectively.

I’m somewhat dubious how reliable 38400 will be. The loop waiting for the falling edge of the start bit is 8 cycles, which introduces unavoidable jittler in the data bit samples:

START0: BITB    PORT            ;  4 - wait for line idle
        BEQ     START0          ;  4
START1: BITB    PORT            ;  4 - wait for start bit
        BNE     START1          ;  4

At 9600 baud this is 1/8 of a bit time. But at 38,400 baud it is a whopping 1/2 of a bit time.

My development cycle is rather long at the moment, as it involves blowing code into a 2716 EPROM. Hence the desire to get a serial port working, then hack one of the 6800 monitors to use it.

There does seem to be quite a few 6800 monitors to choose from:

  • JBUG (as shipped with the MEK6800D2)
  • MIKBUG/MINIBUG (as shipped with the MEK6800D1)
  • SWTBug
  • Smithbug

Not sure yet which one I’m going to use/adapt.


1 Like

Do you know what format the cassette uses. You could get a cassette to 3.5mm jack adaptor and feed it audio from your PC maybe?

If you get serial working then maybe using NoIce would be an option? (Not free software but good for 30 day trial).


I’ve now jumpered the U10 socket so it will accept a 2732 EPROM (a whole 4KB) and got Smithbug compiled and running with a bit-banged serial interface.

Here’s a link to the documentation for Smithbug V1.

And my Smithbug build is now in github.

I chose this monitor because it’s one of the few with a disassembler:

> V 
E000 08 FF A0 1E  08 FF A0 0A  B0 A0 0B F2  A0 0A FE A0      ................
E010 1E A7 00 3F  FE A0 00 6E  00 BF A0 08  8D 66 7D A0      ...?............
E020 18 27 0A 7F  A0 18 8D 3B  27 2E 7E E2  36 FE A0 06      .'.....;'...6...
E030 6E 00 BF A0  08 8D 4D 30  6D 06 26 02  6A 05 6A 06      ......M0..&.....
E040 8D 21 27 14  FF A0 1E A6  02 81 3F 27  07 EE 00 A7      .!'.......?'....
E050 00 FE A0 1E  8D 08 26 EC  BF A0 08 7E  E2 06 08 08      ......&.........
E060 08 5A 39 CE  A0 22 F6 A0  1D 39 8D F7  27 08 C1 05      .Z9.."...9..'...
E070 2C 52 8D EA  26 FC 7C A0  1D B6 A0 1E  A7 00 B6 A0      ,R..&...........
> D 
E000 08 INX                .  
E001 FF STX   $A01E      ...  
E004 08 INX                .  
E005 FF STX   $A00A      ...  
E008 B0 SUBA $A00B      ...  
E00B F2 SBCB $A00A      ...  
E00E FE LDX   $A01E      ...  
 011 A7 STAA 00,X         ..
> R -I-Z-- B=F8 A=FC X=FCF8 PC=F6FC S=01C2 
> I 
> E 0040
> 0040 01 CE
> 0041 01 12
> 0042 01 34
> 0043 01 08
> 0044 01 08
> 0045 01 08
> 0046 01 3F
> 0047 01 
> R -I-Z-- B=F8 A=FC X=FCF8 PC=F6FC S=01C2 
> D 
0040 CE LDX   #$1234     ..4  
0043 08 INX                .  
0044 08 INX                .  
0045 08 INX                .  
0046 3F SWI                ?  
 047 01 NOP                .
> T 
-I-Z-- B=F8 A=FC X=FCF8 S=01C9 
0040 CE LDX   #$1234     ..4  

Smithbug (assembled to $C000) will mostly just co-exist with the resident JBUG monitor. However, not all Smithbug features are currently working. Tracing (which uses SWI) is broken, because the JBUG doesn’t allow the SWI interrupts to be vectored to anywhere else.

To fix that, two changes are needed to JBUG, which add 10 bytes of code:

  1. The JBUG SWI handler (pointed to in FFFA/FFFB) needs to indirect through a vector that Smithbug can change:
LDX SWIVEC   ; Load X with the current SWI handler (3 bytes)
JMP 0,X      ; JMP to X                            (1 bytes)
  1. The JBUG Reset code then needs to set a default value for this vector:
LDX #SWIR    ; Load X with the default SWI handler (3 bytes)
STX SWIVEC   ; Store X in the new SWI vector       (3 bytes)

That’s all very doable and I’ve identified some small optimizations to JBUG that will free up the space.

The main issue is JBUG is in a MCM6830 masked ROM with a very non-standard pinout. So I’ll need to make an adapter board to allow it to take a modern EPROM.

This has been done before, actually several times:



The cassette interface uses 300 baud (Kansas City standard modulation) with a simple block structure that is well documented on page 2-6 of the manual. It would be fairly easy to write some Python or Java to generate this, and I may well have a go at that next.

The system only has 1KB of RAM, so loading a maximum size program at 300 baud will only take 30-40s.

I guess if I wanted to use this for ROM development, I could fit a 2KB static RAM into U10 and somehow bodge a suitable write enable. Or make a small adapter board for a larger RAM.

That’s an interesting idea.

What resources does the 6800 version of Noice need on the target system?

This page seems to suggest that 6800 support isn’t available out of the box:

The standard target monitor, MON6801.ASM uses no 6301 instructions, but does use several instructions not present on the 6800 (LDD, STD, PSHX, PULX). Thus, some modifications of the monitor will be required to use it on the 6800. Please contact us if you need assistance.

I do now have the 6800 instruction set added to the 6502Decoder (link). So this gives me a decent way of debugging anything new that I develop.

What I’m aiming for here is, I think, to try to limit any upgrades that I do to additional ROMs (as might have been developed back in the day). Once I have the power supply sorted (and crowbar protection added), I’ll probably put the MEK6800D2 boards back in the original brief case.


1 Like

I’ve dug out my 6800 code and stuck it on GitHub

Here’s my effort at getting it to work on a BBC Micro with the 6800 as the main CPU. You should be able to reduce the size of COMBUF to 20 bytes or so - I set it to 128 because I was transferring large memory dumps.

It should be fairly simple to tweak to use whatever serial you have. handshaking isn’t really an issue as when it wants to receive it sits in a tight loop so don’t bother with RTS/CTS etc for NoIce.


1 Like