![[haygood]](haygood_32K.jpg)
Most recent revision date of this page, Oct 9 2023. Copyright 2023 Herb Johnson.
I cover Motorola's 6800 MIKbug and a varient SMITHbug, on another Web page. In Oct 2023 I was contacted by Ged Haywood, who worked with MIKBUG and the early Motorola EXORciser. Here's what he told me about the varient he created called "BUGGED". - Herb Johnson
I was one of the first few people to use the MC6800 for anything. It was 1975, and I worked at [a research organization in the UK]. I can't tell you about the work but I can tell you, I used MIKBUG a lot. In those days we had paper tape punches and readers for code - a big step up from punched cards. I got MIKBUG going when we first used the Motorola development kit called the 'EXORciser'. Paper tapes were both read and punched by a 'Teletype' ASR-33 until we bought something a bit zippier. I had to get a pair of ear defenders from stores or I'd have gone deaf. Ten rather loud characters per second, sometimes for hours at a time ..
MIKBUG was evidently written before Motorola had managed to get their asynchronous comms chip (the MC6850 ACIA) out of the door. [So MIKBUG] used loop counting plus reading and/or waggling bits on a MC6820 'PIA' to sense or drive the serial interface signals [as a software UART].
At the time I thought this could be much improved, so that the interrupt facility of the CPU could be employed and free the CPU for other tasks. I always had lots of other tasks for it to do.
So I modified MIKBUG to use the serial interface chip, and later on added a few extra commands which I found useful. During the following years I used this tool a great deal, building it into more or less all the kit that I designed which employed the MC6800. For reasons which will, I guess, become obvious I called the improved tool 'BUGGED'.
Copies are attached if you're interested. Do what you like with them. If you read the code, you'll see that the earlier of the two versions was stored on paper tape. I guess we used no magnetic media for data storage until around 1978. I still have that paper tape.
It's very odd how (human) memory works. I can remember only that it was my first use of software interrupts. Although I can remember many of the MC6800 opcodes (like 86, load immediate accumulator A; 3F, SWI) I can't remember anything of the instruction set for the AMD9511. For some reason the MC6800 instructions always used to rattle around in my head. On the way home on my bike, I could never seem to stop them. The idea of using software interrupts came to me while I was in bed, in a hotel in the USA.
It was all about keeping the size of the code to the absolute minimum, because we were always so strapped for storage space. While I was [in the USA], I remember calling one of my people in England to discuss the idea, and set him on the path to the first attempt at the code. I'd had to place the call via the hotel operator, and after the call was over she called me back and said, "Did you just make a 55 minute call to England?!"
The SWI idea worked really well (we kind of implemented reverse Polish and that improved the efficiency a lot), but when we first got it working there was still no need for us to write an ORIGIN directive for the interrupt vectors. As you probably know, they were four words at the very top of the ROM. The rest of the code used all but the very last four words of the ROM. Quite a squeeze.
The EXORciser was one of the original [models]. We used its slots as a template for our own circuit boards. They'd fit in the EXORciser, but eventually we did all the development on the instruments themselves as it was more convenient and the EXORciser fell out of use. [The EXORciser bus implemented Motorola's EXORbus.]
We had problems with the early MCM6810 128 byte RAM. It would be a bit sensitive to all the address lines changing at once. The recovered data could be corrupted. I couldn't prove it until we bought a logic analyzer but then it was very clear to see what was happening on the screen. I remember sending a batch of about 100 back to our supplier for replacement because of that problem.
Motorola USA [and our UK Motorola supplier] put on a one-day course for people just starting to work with the 6800. That was probably the most rewarding course I ever attended.
![[haygood]](haygood_6809.jpg)
[I found two of our developement] cards on a shelf here, from the late 1970s. As soon as I saw one of the plug-in cards, I knew it had a 43-way edge connector. Go figure. I recalled that by the end of the 1970s or maybe early 80s we had one for something like 32kBytes of static RAM. The RAM more or less completely filled that board.
Both are prototypes of cards of the size to fit the EXORciser. One card contains 32kbytes of static RAM (implemented with MOSTEK 2kx8 chips). The other contains an MC6809 CPU with 32kbytes of EEPROM (2764), 2kbytes + 256bytes of RAM, an AMD9511 hardware floating point chip, plus a lot of ancillary stuff for the instrument that it worked in.
The reason the CPU card carried two different blocks of RAM, is that data was fed to the 256 byte block by DMA. It isn't a general purpose card (a fair bit of the card's real estate is taken by the instrument's data collection circuits) but occasionally it would have been used that way.
On one of the [CPU's] EEPROM labels is a date in 1986. I don't remember what I was doing with the cards in 1986 - I was doing a lot of freelance electronics design then. Development work of some kind I guess, because it looks like there's a BASIC interpreter (and another version of BUGGED!) in two of the chips. I've no idea if the cards are still working, I no longer have access to any of the equipment in which they would have operated.
I think we used the AMD coprocessor after the first one we used [probably a calculator chip] proved to be rather too slow. I'm pretty sure it was taking upwards of half a second to do some of the floating point calculations we needed to do: unacceptable in practice. The AMD chip was very much faster, but its power consumption (relative to the chip it replaced) was horrific. So I had to switch its power off while the instruments were collecting data and only power it up when it was time to do the maths. [I used] one of the bits on a MC6820 to control the AMD power.
BASIC was really just a convenience for trying things in development. We never used BASIC code in the completed instruments. The interface with the coprocessor was written in assembler like everything else.
All the board communication was by means of the (9600 bits per second) serial port, which was provided on our instruments as standard anyway. We didn't have to change hardware designs at all [to use other development tools].
We tried Pascal in the late 1970s, but it was a disaster because the compilers that we could get were riddled [with errors]. I remember flying to Boston (MA) with a printout showing proof of all the bugs we'd found because one author wouldn't accept what we said over the telephone. Obviously today we'd just email them but nobody really used email in those days. Until then I don't think I'd ever found a bug in a compiler, I guess that tells you how experienced I was.
The fact that RTL/2 was used by ICI in chemical process plants was attractive to me, as I was also working in high-stakes environments. That was one of the main selling points. The manual said "the basic language definition is therefore frozen and there are no plans for further extension or modification" which was a big plus for me.
In complete contrast to Motorola books about their microprocessors (they were paperback books, several hundred pages each, and they gave them away by the thousand); there [were only] a very few copies [of RTL/2 documents] and they were jealously guarded. DEC's PDP-11 and RSX-11 documentation was the Gold Standard. It came in a big crate. When you opened the crate, right there on top was a volume with "READ THIS FIRST" on the front cover. You could buy extra copies for some hundreds of pounds per section.
When we switched to RTL/2 we worked out a system, where we ran Xenix on our PDP-11 in the mornings, when the folks who did the administration and documentation etc. could use it. In the afternoons we ran RSX-11, so the development people could get on with RTL/2 work. It often happened, that development could go on into the night. It wasn't unusual for me to work all through the night when I had the computer to myself to crack some knotty problem.
[So] We moved to RTL/2, and that was a lot better from that point of view, but it could never compete with assembler for efficiency. Much more important to us than the [RTL/2] compiler itself was the development system that it came with. It had its own chunk of ROM in the instrument, providing things like single-stepping. Sort of like a MIKBUG with bells on.
On top of that, the authors of this [RTL/2] system were in a town called Abingdon which was about six miles away, rather than three thousand miles away [in the USA} on another continent. We thought it was slick at the time, but doing things that way now (I sometimes still do!) feels kinda clunky. I don't know how we found the people in Abingdon, they certainly weren't on the Internet because it didn't yet exist. [Because of the pricing for RTL/2] it was always going to be an uphill struggle for RTL/2 to be widely adopted. Within a few years of [its release] the Personal Computer took hold, and respectable C compilers came out for microprocessors (and they became capable of properly supporting them). In the late 70s and early 80s I was paying tens of thousands of pounds for computers, their operating systems (Xenix, RSX-11). But the compilers by 1985 were selling for 100 dollars or so. So in retrospect RTL/2 was never going to fly.
Around the mid-1980s I began to use the Zorland (later Zortech) C/C++ compiler. I think I paid fifty quid for it. I *still* use it.
I'm sure that most of the code is still around here somewhere, but it will be on paper listings I'm afraid, not on magnetic media ... If it turns up I'll scan the code and let you have it.
With Zortech C/C++, I produced software for a small family business I started here in Derbyshire. Computers enabled us to more or less take over the entire market in the midlands of England for a very wide range of products (commercial stationery), simply because we were so much more efficient than the competition.
To be perfectly honest I'm not sure that I was as fully aware as I might have been, that what was happening was part of an industrial revolution, although even then I often said it to people.
I like to tell this story: after a couple of years of using the computer to do all the arithmetic for invoicing our customers, I decided one day it would be a good idea just to check that we could still do the job manually. So one weekend we went in to do that and it took us all morning to get two accounts completely wrong. It was quite clear we couldn't survive if we couldn't depend on our computer.
So I ordered a spare computer. At the time the PCs we were using (5MHz 8086, 512k RAM, 10MByte HD, 720k floppy) were about 3,000 UKP each. I wrote to the manufacturer to say what great value for money it was.
- Ged Haywood
I looked around the Web, for information on "RTL/2" and microprocessors like the 6800. What I found, were references to a design language called RTL/1, followed by RTL/2. These were designed by a UK company called ICI, in the early 1970's for use with minicomputers like the DEC PDP-11 and IBM's mainframe System 360. It was marketed and developed by other UK companies and at some point a standard for RTL/2 was established. Wikipedia has some background information. Web search suggests RTL/2 was mostly used by companies in the UK.
From DEC's "software Sourcebook V2, 1986"
RTL/2 (Real-Time Language)
PDP-11 Operating System: RSX
This high-level, structured, ALGOL-based Pascal-like language is designed for use in real-time computing and is especially suited for the programming of on-line data collection, real-time monitoring, and control. RTL/2 is strongly typed and supports modularity, reentrancy, recursion, multitasking, and assembly language code inserts. RTL/2 is used worldwide at more than 500 installations. The language is British Standard BS5904. The system has no subsets or supersets to affect transportability between different vendor computers. A source code¬ level Symbolic Debug Package comes with the compiler.
A version of this product is available for VAX computers.
Price: $3000
A developer who used RTL/2, set up some explanations on their Web site and also a brief document from a developing company
From an early 1980's Master's Thesis:
Recently a micro-RTL/2 for Intel, Motorola and Zilog microcomputers was announced. These new compilers will use the time-honored technique of translation to an intermediate language, followed by interpretation (as with UCSD-Pascal) in order to achieve portability.
Further wandering on the Web, eventually found this fruitful site about the "Phillips P800" minicomputer, which supported RTL/2. The P800, also described on the site, was a UK minicomputer of the 1970's. Looks like it had 14 registers and a program counter and a stack pointer, 16 bits, with relative and indexed addressing. Also some kind of memory management and segmentation. - Herb Johnson
Copyright © 2023 Herb Johnson except for content provided by Ged Haywood
