Motorola started it in 1975 with the EXORciser which ran a monitor / debugger called EXBUG (EXorciser deBUGger). This was followed by the M6800 Evaluation Module and the MEK6800D1, both with MIKBUG written by Mike Wiles.
I can't find any evidence of this, either way, but I strongly suspect MIKBUG is short for MIKe's deBUGger, shortened to six characters to work with the assembler Motorola was using at the time (the other monitor / debugger of the time was MINIBUG (or MINI-BUG), called MINIB in the source code).
After that, pretty much everyone called their monitor program somethingBUG. The list includes SWTBUG from Southwest Technical Products, GMXBUG from Gimix, MSIBUG from Midwest Scientific Instruments, SMARTBUG from Smoke Signal Broadcasting, JOEBUG by Joe Pentecost and EDBUG by Ed Smith. And of course some people were less staid, Computerware Software Services had DOODLEBUG and Pete Stark had HUMBUG.
In the July 1980 kilobaud, Pete describes HUMBUG as follows:
HUMBUG is an extended monitor intended as a SWTBUG/MIKBUG replacement. My standard version occupies three 2708 EPROMs and requires a separate EPROM board; a 2K version of HUMBUG, which fits into a 2716 EPROM and fits on the MP-A2 CPU board, also exists.
In designing HUMBUG, I had the following criteria in mind: 1. SWTBUG subroutine entry points had to be preserved so other programs would run unchanged. SWTBUG scratchpad addresses also had to stay the same. 2. I wanted full control over the system from the keyboard, including turning ports on and off in the midst of a program and aborting programs from the keyboard without pushing RESET. 3. I needed extended debugging facilities for machine- and assembly-language programming. I was not happy with the way SWTBUG handled breakpoints and stack pointers in user programs, since it would make an occasional annoying error. I also wanted a single-step mode for stepping through programs under test. 4. Finally, I expected HUMBUG to change with time and wanted to make it easily extended to new functions without major rework.
In August and September he discusses the various functions and gives pretty much a complete listing of HUMBUG/6800. I learned a lot from these articles.
The December 1981 column mentions porting HUMBUG to the 6809 but doesn't provide any technical information. The February 1982 also briefly mentions HUMBUG -- this was Pete's last column in the by then "kilobaud MICROCOMPUTING" -- this was shortly before they dropped the "kilobaud", becoming just MICROCOMPUTING and shortly thereafter, history.
The source code for HUMBUG for the PT-68K is available for non-commercial use by accepting this agreement on Peter Stark's website.
Attempting to compile this code using the Quelo cross-assembler gives a whole bunch of errors.
>>> ERROR line Invalid opcode  M:P4HUMBUG.A68 1. NAM HUMBUG / 68K (R) >>> WARNING line Option not implemented  M:P4HUMBUG.A68 2. OPT PAG >>> ERROR line Invalid opcode  M:P4HUMBUG.A68 3. PAG
Well, that's just prettyprinting, we don't need it.
>>> ERROR line Invalid opcode  M:P4HUMBUG.A68 141. EVEN
Aligning the code to an even address is essential. Quelo uses
DS.W 0("Define Storage".Word) to define an array of words, 0 words long -- which has the side-effect of forcing a word align.
* EVEN EVEN MACRO DS.W 0 WRM MACRO: Align to Word boundary ENDMtakes care of that.
>>> ERROR line Invalid opcode  M:P4HUMBUG.A68 00F80384 485. COMTAB FCC 'AD' FORMATTED ASCII DUMP >>> ERROR line Invalid opcode  M:P4HUMBUG.A68 00F80656 776. CRLFST FCB $0D,$0A,4
"FCC" is a pseudo-operator "Form Constant Character" which stores the string in the code. In the same way, "FCB" stores bytes. As far as I can tell this is equivalent to DC.B, DC.W, and DC.L ("Define Constant".Size)
While* FCB $0D,$0A,4 FCB MACRO DC.B \1 WRM MACRO: FCB IFNC '\2','' DC.B \2 ENDC IFNC '\3','' DC.B \3 ENDC ENDMseems to take care of FCB, the preprocessor thinks a space is a space even inside a string, so the same approach does not work with something likeFCC 'This is a string'
For now, search-and-replace is probably our friend.
I don't quite understand the remaining issue that you will need to fix to compile HUMBUG with the Quelo assembler. BTST is always a byte operator (BTST.B) except when operating in Data Register Direct mode, when it is a long (BTST.L). This is what the 68000 manual tells me, although I don't know why they would have implemented it like this, doesn't make sense to me.
Anyway, Quelo wants you to specify BTST.B instead of just using BTST as HUMBUG does. Also, you need to change the BTST.W instructions to BTST.L. BTST.W? Yea, I said, I don't understand this. If you can provide me with more insight, please email.
||Back to Wouter's 68000 Page||(This page last modified 2020-06-14)|