Monday, January 30, 2023

Forty Years of Personal Computing - BBUG


In the early 1980s, I was excited about the MC6809 processor. I wanted one. But my student budget couldn't afford it. I studied all material about the MC6809 I could get my hands on.

In 1981, I obtained the source code to SBUG-E, the SWTPc ROM monitor for the MP-09 board. I was familiar with the source code to the MC6800 ROM monitors MIKBUG and SWTBUG. SBUG-E demonstrated the elegance of the MC6809 processor.

As I understood SBUG-E, I wasn't satisfied with it. I began to modify the source to suit my own purpose.  I called this resulting monitor BBUG. 

I worked on BBUG for a couple of years, off and on. My earliest printout is from April 1981. I wrote code using a cross-assembler and pour over the listings. I hunted for ways to make BBUG compact, as it had to fit in a 2 KB ROM. But the code never ran until I built the Homebrew MC6809 CPU board in mid-1983. (Which is another story)

BBUG's command structure is similar to SBUG-E, as is a lot of the code. Here are the differences.

Commands Removed

I removed several commands from SBUG-E. My plan for an MC6809 computer had floppy disks, so the cassette tape operations were the first to go. The DMAF1/2 8" disk system seemed incredibly expensive, so I removed that boot command, and used the D command character for an SS-30 floppy disk controller boot. Finally, the stack memory dump didn't seem useful to me, so I pulled it, too.

In summary:

  • D - no DMAF1/DMAF2 boot - no DMAFx 8" disk controller
  • L - no cassette tape operation
  • P - no cassette tape operation 
  • S - stack memory dump didn't seem useful
  • U - changed this command to D, see below

Commands Added

I added a couple of new commands for BBUG. The first was a memory fill command. SWTBUG had this as well. I also added a help command.
  • F start-end byte - Fill Memory from start to end address with given byte value
  • Z - Help - prints a summary of commands

Other Changes / Refactorings

Other parts of SBUG-E were re-written and improved:
  • Q - I spent some time in college investigating memory test methods. I re-wrote this test to use a modulo 255 memory convergence test with nine total passes. This is a fast test that detects most kinds of memory errors.
  • U - Changed this command to D and completely re-wrote as an improved boot from an SS-30 Floppy Disk Controller. Major changes include:
    • Performs up to sixteen tries, allowing recovery from soft errors.
    • Alternates single and double density between tries, so it can boot from double-density disks.
    • Works with FD1771 and WD2797 controller chips
    • Works with 5 1/4" and 8" versions of controller board (more on this later)
  • Command code positioned in alphabetical order in source. This made no difference in the space requirements or efficiency of the monitor, but it made it much easier to find the commands I was working on.
  • Alter register commands refactored to use less space.
The last iteration of BBUG v1.91 fits in a 2 KB EPROM with 1 byte to spare. 

4 KB Version

In October 1986, I experimented with expanding BBUG to fit a 4 KB ROM. This version has a test string at address F000, and the rest of BBUG at address F800. You can see this version at the bottom left in the picture above. 

The test was successful, and this left space for more commands. At that point, however, I was more interested in OS-9, and had less use for BBUG.

Future Changes

If I make any future modifications to BBUG, the first thing I'd do is a fix a bug. The extended memory initialization assumes that the E-block is at physical address FE000, so it writes F1 into that block. That's not compatible with the current Homebrew MC6809 V2 board (which is another story), where the value should be 01 instead. This would also match the value written by OS-9 Level 1. 

There's also 2 KB of additional space for more commands. Extended memory functions would be welcome. A command to catalog all the extended memory blocks would be useful, as well as running memory tests on extended memory blocks. That would be a start. And I might bring back the stack memory dump command.

No comments:

Post a Comment