SUPERMON 816

[BigDumbDinosaur]

• ————————————————————————————————————————————————————————
  Supermon 816 is available for download from my POC website.  See the DOWNLOADS page.  Detailed documentation is included with the download.
  ————————————————————————————————————————————————————————

Supermon 816 is a derivation of the machine language monitor in POC V1.1's firmware and should be able to run on almost any 65C816 system operating in native mode, assuming that some basic console I/O facilities are present.  The source code will assemble in Daryl Rictor’s modified version of Mike Kowalski’s 65C02 editor/assembler/simulator, and the resulting binary has been tested by running it as an application on POC V1.1, V1.2 and V1.3.  Porting Supermon 816 to other assemblers shouldn't be difficult.

——————————
About the Name
——————————
I'm sure most of you have heard of Supermon, which was the machine language monitor that the late Jim Butterfield packaged for the Commodore PET/CBM computers, and then adapted to the C-64, resulting in Supermon 64.  Back in the day, I made extensive use of Supermon 64 and thus its operation has become burned into my back brain.  I should note that Commodore evidently thought that Supermon 64 was a fine piece of software as well, as the resident M/L monitor in the C-128 was essentially Supermon 64 with additional features and support for the C-128's memory architecture.  Lloyd Sponenburgh and Roy Southwick of Fiscal Information also thought that Supermon 64 was exemplary, as they based their LKMON disk editing program for the Lt. Kernal hard drive subsystem on it.

When I designed the machine language monitor for POC, I decided to use a user interface with which I was intimately familiar, even though it was clear that the monitor itself would have to be scratched-written to support the 65C816 in native mode.  Following the decision to separate the monitor from POC's firmware and make it a standalone program, I needed to come up with a name for the project.  I decided it would be fitting to perpetuate the name of what was (and probably still is) an indispensable programming tool for Commodore assembly language developers.  Hence Supermon 816.

[BigDumbDinosaur]

Supermon 816 includes the following features:

• Assembler and disassembler, supporting all 65C816 instructions and addressing modes;
• Code execution;
• Memory compare, copy, dump, fill, modify and search;
• MPU register dump and modify;
• Number base conversion;
• 24 bit addressing.

Commands are as follows:

• A — Assemble code
  Syntax: A <addr> <mnemonic> [<operand>]
  
  Upon successful assembly of an instruction, Supermon 816 will disassemble and display the instruction, and then prompt for the next instruction.  Pressing the enter (return) key (notated as <CR>) at the prompt will discontinue assembly.
  
  With the exception of REP and SEP, all immediate mode instructions may be assembled with 8 or 16 bit operands.  For example:
  

  Code: Select all

  LDA #$12AB

  If the operand is less than $0100 and it is desired to assemble it as a 16 bit value, precede the operand field with an exclamation point (!).  For example:
  

  Code: Select all

  a 1f2000 lda !#$4

  The above will assemble as:
  

  Code: Select all

  A 1F2000  A9 04 00     LDA #$0004

• C — Compare memory regions
  Syntax: C <start> <end> <reference>
• D — Disassemble code
  Syntax: D [<start> [<end>]]
  
  If no addresses are given, code will be disassembled starting at the last known address, which will be $000000 when Supermon is started.  Disassembly includes both the byte(s) in each instruction and the assembly language equivalent.
• F — Fill memory region
  Syntax: F <start> <end> <fill>
  
  <start> and <end> must be in the same bank.  <fill> may be any byte value.  Be careful to not accidentally overwrite key system areas or Supermon 816 with this command.
• G — Execute code
  Syntax: G [<addr>]
  
  If <addr> is not specified code will be executed at the bank and address displayed by the R (dump registers) command.  A BRK instruction will return control to Supermon 128 if the VECBRKI vector has been set up in your operating environment.
• H — Search (hunt) memory region
  Syntax: H <start> <end> <pattern>
  
  <pattern> may be entered as a set of whitespace-separated byte values or as a character string.  If the latter, use the following syntax:
  
  • H <start> <end> '<character string>
• J — Execute code as a subroutine
  Syntax: J <addr>
  
  If <addr> is not specified code will be executed at the bank and address displayed by the R (dump registers) command.  A final JSR instruction in the executing code block will return control to Supermon 128 if the hardware stack remains balanced.  Upon return to Supermon 128, the registers will be dumped before entering the input loop.  Hence this command may be used to test a subroutine without having to set a BReaK point.
• M — Dump memory range
  Syntax: M [<start> [<end>]]
  
  If no addresses are given, memory will be displayed in both hex and ASCII formats, starting at the last known address, which will be $000000 when Supermon is started.  If only <start> is specified, 256 bytes will be dumped, starting at <start>.
• R — Dump 65C816 registers
  Syntax: R
  
  The dump is as follows:

  Code: Select all

    PB  PC   nvmxdizc  .C   .X   .Y   SP   DP  DB
  ; 02 083A  00110000 1234 5678 9ABC CDFF 0000 DE

  displaying the program bank, program counter, status register, 16 bit accumulator, 16 bit X- and Y-registers, stack pointer, direct page pointer and data bank.  These values will be loaded into the 65C816's registers when a G or J command is executed.
• T — Copy (transfer) memory region
  Syntax: T <start> <end> <target>
  
  <start> and <end> must be in the same bank.  <target> may be in any bank.  If <start> and <target> are the same Supermon 816 will issue a diagnostic.
• X — Exit Supermon 816
  Syntax : X
• > — Modify memory
  Syntax: > <addr> <pattern>
  
  <pattern> may be entered as a set of whitespace-separated byte values or as a character string.  If the latter, use the following syntax:
  
  • > <addr> '<character string>
  A maximum of 32 bytes may be entered.
• ; — Modify 65C816 registers
  Syntax: ; [<PB> [<PC> [<SR>...etc.
  
  Enter the new register values in the same order as they are displayed in a register dump.  You need only enter enough values to include the last one you want to change.  Issuing this command without any parameters will dump the registers and return to the input prompt.
• radix — convert a number to all supported bases
  Syntax: %|@|+|$<number>
  
  For example:

  Code: Select all

  +1234567 <CR>

  will display:
  

  Code: Select all

      $12D687
      +1234567
      @04553207
      %100101101011010000111

  Radix symbols are:
  
  • % — binary
    @ — octal
    + — decimal
    $ — hexadecimal
  The largest number that can be converted is 4,294,967,295 (%11111111111111111111111111111111, @37777777777 or $FFFFFFFF).

All numeric values, be they addresses, instruction operands or other values, may be entered with any of the above radix symbols for on-the-fly conversion.  If no radix precedes a numeric value, hex will be assumed.

[chitselb]

can it Walk through code?

[BigDumbDinosaur]

chitselb wrote:

can it Walk through code?

If you mean single-stepping, no.

Proper support of single-stepping with the 65C816 is more involved than with the 65C02, and with the POC series constrained to the hardware that would fit on an EPCB Proto-Pro board, I would not have been able to add the extra logic that would be required to stop the '816 on each opcode fetch and dump registers. Aside from that, I've never really found a need for single-stepping as a software debugging tool, so I didn't give it any consideration when I designed POC and its firmware.

Anyone who has a system that has the necessary hardware to allow single-stepping of the '816 can easily modify Supermon 816 to work with it.

[White Flame]

In theory, you could do single-stepping for most cases purely in software by swapping the potential next instructions' opcode with 0, and have BRK pop back into your monitor. It's obviously not 100% fool-proof, though. Has any monitor actually done this?

[Dr Jefyll]

BigDumbDinosaur wrote:

I've never really found a need for single-stepping

Same here. But the hardware to support it is minimal -- basically a NAND gate and a SPST switch. Of course even that could be a problem on an EPCB Proto-Pro board. In case anyone's interested, there's further info here. For '816 you'd need a 3-input NAND (not 2) to accept VPA and VDA instead of SYNC.

cheers
Jeff

[teamtempest]

Quote:

In theory, you could do single-stepping for most cases purely in software by swapping the potential next instructions' opcode with 0, and have BRK pop back into your monitor. It's obviously not 100% fool-proof, though. Has any monitor actually done this?

Not in a monitor, but I did once debug an interpreter this way by replacing an opcode in its instruction fetch loop with BRK. The single stepping did eventually reveal that a CLC instruction plainly written down on paper somehow did not make it into the assembler's actual input.

[lordbubsy]

Beautiful! I’m definitely going to use it, as soon as MARC-2 is operational.

As for single stepping, on MARC-2 I have connected all pins of the ‘816 to the CPLD and enough programming resources to include it. I’ll have to seek out how to implement it though.

[Rob Finch]

I'm trying to port this already. It looks great. What I'm wondering is how the labels work, what's with the decimal numbers ?

.0000010

My assembler gives me errors for multiple definitions of the labels. The labels are used more than once. So how do they work ?

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

I've never really found a need for single-stepping

Same here. But the hardware to support it is minimal -- basically a NAND gate and a SPST switch.

That would allow one to halt the '816 on each opcode fetch (VDA && VPA), but it wouldn't do anything else. If the programmer is curious about register contents at each step in the program, then the circuit has to do much more. Otherwise, all that could be done is watch the address and data buses with a probe, logic analyzer or 'scope, which isn't all that beneficial for software debugging (but quite useful for finding a hardware bug).

What I would envision is having the system display the registers when the '816 halts at the next opcode fetch, since the registers would reflect the computational result of the previous instruction. The ideal, I think, would be to have to M/L monitor regain control so that in addition to the registers being displayed, one could examine memory, see what's going on with the stack, etc. So, the single-step logic would have to be able to trigger an interrupt at the opcode fetch, but only once until the use restarts execution of the program under test. This is what I was alluding to when I made the comment about using up PCB real estate. It would take much more than a NAND gate and a switch.

[Dr Jefyll]

BigDumbDinosaur wrote:

That would allow one to halt the '816 on each opcode fetch (VDA && VPA), but it wouldn't do anything else.

I don't understand why you'd say that. But I've use the KIM-1 in single-step mode, and can promise you it does work.

BigDumbDinosaur wrote:

The ideal, I think, would be to have to M/L monitor regain control so that in addition to the registers being displayed, one could examine memory, see what's going on with the stack, etc.

The KIM-1 and its firmware do just that. The hardware cost, in dollars and board space, is trivial -- it's the firmware that does most of the work.

ETA:

Quote:

So, the single-step logic would have to be able to trigger an interrupt at the opcode fetch, but only once

Yes. And a sneaky way to do it is to tap onto some Chip-Select signals. The MOS Technology approach assumes the monitor code is stored in some sort of ROM, and the (presumably experimental) code being single-stepped is stored in RAM. Opcode fetches from RAM produce NMI's. Opcode fetches from ROM don't.

-- Jeff

[BigDumbDinosaur]

Rob Finch wrote:

I'm trying to port this already. It looks great. What I'm wondering is how the labels work, what's with the decimal numbers ?

.0000010

My assembler gives me errors for multiple definitions of the labels. The labels are used more than once. So how do they work ?

A label such as .0000010 is a "local label," whose scope is bounded by the nearest "global labels," that is, labels whose names don't start with a dot (.). For example:

Code: Select all

GLOBAL01 <——— a global label

.0000010 <——— a local label <———+
                                |
         goto .0000010 —————————+

.0000020 <——————————————————————+
                                |
         goto .0000020 —————————+


GLOBAL02 <——— another global label

.0000010 <——————————————————————+
                                |
         goto .0000010 —————————+

         if some condition
           goto .0000020       ;won't work, as .0000020 isn't in scope

GLOBAL03 etc.

The local labels .0000010 in each code segment have no relationship to each other because they are bound by the global labels. Also, the second segment can't "see" .0000020 in the first segment because of the interceding global label GLOBAL02.

In some other assemblers (e.g., Commodore's DevPak 128), a local label is denoted with a trailing dollar sign, e.g., 0000010$. If your assembler doesn't support local labels then you'll have to concoct some new label names to replace them.

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

That would allow one to halt the '816 on each opcode fetch (VDA && VPA), but it wouldn't do anything else.

I don't understand why you'd say that. But I've use the KIM-1 in single-step mode, and can promise you it does work.

Does KIM-1 use interrupts for I/O processing? In the POC, all I/O is interrupt-driven, so merely halting the MPU on an opcode fetch (e.g., by asserting RDY) would preclude anything from working.

Quote:

Quote:

The ideal, I think, would be to have to M/L monitor regain control so that in addition to the registers being displayed, one could examine memory, see what's going on with the stack, etc.

The KIM-1 and its firmware do just that. The hardware cost, in dollars and board space, is trivial -- it's the firmware that does most of the work.

I did work out a circuit to do it with POC at one time, but it wasn't trivial, since it wasn't just a case of single-stepping the MPU, but actually causing some sort of interrupt that would allow the M/L monitor (or at least part of it) to regain control until something was done to restart the program under test. The logic wasn't simple and as I wasn't experiencing a fulminating lust for single-stepping, I abandoned the idea.

[BigDumbDinosaur]

Dr Jefyll wrote:

ETA:

Quote:

So, the single-step logic would have to be able to trigger an interrupt at the opcode fetch, but only once

Yes. And a sneaky way to do it is to tap onto some Chip-Select signals. The MOS Technology approach assumes the monitor code is stored in some sort of ROM, and the (presumably experimental) code being single-stepped is stored in RAM. Opcode fetches from RAM produce NMI's. Opcode fetches from ROM don't.

I can't use that method with POC (which I did consider early on), as some M/L monitor functions execute code snippets in RAM, although the monitor itself is ensconced in ROM. In POC V2, the possibility will exist for the entire firmware to be shadowed in RAM, so anything that might be done to enable single-stepping cannot make any assumptions about code location.

Incidentally, I had considered trying to implement single-stepping using the '816's ABORTB input, but scrapped that idea because an ABORTB interrupt restarts at the "aborted" instruction.

[Dr Jefyll]

BigDumbDinosaur wrote:

some M/L monitor functions execute code snippets in RAM

'kay, that makes sense. Given that peculiarity (specific to the POC), you'd need some way to mask the non-maskable interrupt... except during times you're sure it's the test code whose opcode you're about to fetch.

BigDumbDinosaur wrote:

Dr Jefyll wrote:

Same here. But the hardware to support it is minimal -- basically a NAND gate and a SPST switch.

That would allow one to halt the '816 on each opcode fetch (VDA && VPA), but it wouldn't do anything else. If the programmer is curious about register contents at each step in the program, then the circuit has to do much more. Otherwise, all that could be done is watch the address and data buses with a probe, logic analyzer or 'scope

Hmph! It's remarkable that you're willing to tell us a technique deployed by MOS Technology and used by thousands of KIM-1 owners wouldn't work. KIM-1 is a different context than POC, but your comments about the need for logic analyzers and 'scopes have no bearing in either case -- you don't seem to have grasped the point, and were perhaps talking about something else entirely (maybe your "circuit to do it with POC at one time, but it wasn't trivial").

In another thread you said, "I type faster than I think, so words sometimes get lost in the process." Maybe it'd be a good idea for you to type (and hit Submit) a little more slowly next time.

Thanks for sharing SUPERMON 816 with us, though.

-- Jeff