All the BUGs

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.

Peter Stark

Peter Stark K2OAW was a frequent contributor to 73 Magazine, and when Wayne Green started kilobaud magazine he was in there with an article in issue #1 -- all about programming HP programmable calculators. That wasn't too exciting, at least not to me, but somewhere along the way he obtained a Southwest Technical Products (SWTP) computer, and started documenting his "Thoughts on the SWTP Computer System" starting with the March 1979 issue of kilobaud.

Peter Stark passed away on 2022-09-17.

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.

HUMBUG 68K

The source code for HUMBUG for the PT-68K was available for non-commercial use by accepting this agreement which is now on the Wayback Machine -- as far as I know Peter Stark retired from the internet because of health reasons.

Attempting to compile this code using the Quelo cross-assembler gives a whole bunch of errors. 

>>>  ERROR  line[1] Invalid opcode   [1] M:P4HUMBUG.A68
                            1.            NAM HUMBUG / 68K (R)
>>> WARNING line[2] Option not implemented   [2] M:P4HUMBUG.A68
                            2.            OPT PAG
>>>  ERROR  line[3] Invalid opcode   [3] M:P4HUMBUG.A68
                            3.            PAG

Well, that's just prettyprinting, we don't need it. 

                            
>>>  ERROR  line[141] Invalid opcode   [141] 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
          ENDM

takes care of that.



  
>>>  ERROR  line[485] Invalid opcode   [485] M:P4HUMBUG.A68
00F80384                  485.  COMTAB    FCC 'AD' FORMATTED ASCII DUMP

>>>  ERROR  line[776] Invalid opcode   [776] 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
          ENDM


seems 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 like

          FCC '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.










[Image] Hit Count

hits since 2014-03-19.




Back to Wouter's 68000 Page


(This page last modified
2022-10-19)